From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E3FC913897B for ; Sun, 10 Feb 2013 20:56:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4DF4D21C0F6; Sun, 10 Feb 2013 20:55:57 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8ED6721C0E3 for ; Sun, 10 Feb 2013 20:55:55 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id o1so2493890wic.11 for ; Sun, 10 Feb 2013 12:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DmFz9n0DAU6kfVgEMVTmEgdCx0YK2Kh7Sc5BjTlCV0o=; b=OjPQmje/ymDosdLR+k0C5zWtMQqe4lJ2UTS9ASgOE2IIeBDTq1rJqee2IJPM+iHrsi TSrFWDazShTidoqZGp0rokbWCClr+6lzZECSiaot5W85kuDsrHNnGogzI57ih/wd0az2 lAjj17plI53SzgZXqDevjcUQp5MtWngElb4XbCn/JyW0VIhGogRwleTofhff1zt27YAo LZQ61zaMWsrMMxgiAlJdbAsK7wvphIF5tBeYjowo2Ep8yglV2gDUot9+jxCRBlS4Bu32 eTF+3cklfPxoDRsah0mJ7ymY3AzQebz3DDWRkTJ/FTSnL8kv4fopvKWNgAEdzfy3QnpQ 0qsw== X-Received: by 10.194.235.225 with SMTP id up1mr20282109wjc.11.1360529754279; Sun, 10 Feb 2013 12:55:54 -0800 (PST) Received: from [172.20.0.41] (196-215-209-80.dynamic.isadsl.co.za. [196.215.209.80]) by mx.google.com with ESMTPS id m6sm28954115wic.2.2013.02.10.12.55.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Feb 2013 12:55:53 -0800 (PST) Message-ID: <51180915.6090007@gmail.com> Date: Sun, 10 Feb 2013 22:54:45 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130114 Thunderbird/17.0.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] What to do with /var/run? References: <51175A29.3090002@binarywings.net> <51179534.4080308@gmail.com> <21471.1360510152@ccs.covici.com> <5117C2FD.7040301@gmail.com> <31886.1360514792@ccs.covici.com> <5117D2F3.9080203@binarywings.net> <9390.1360519297@ccs.covici.com> In-Reply-To: <9390.1360519297@ccs.covici.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 31106f23-7eda-4f5b-aa36-b7a7e2067f33 X-Archives-Hash: d25190b14169f5fbe17098dc7d3a3075 On 10/02/2013 20:01, covici@ccs.covici.com wrote: > Florian Philipp wrote: > >> Am 10.02.2013 17:46, schrieb covici@ccs.covici.com: >>> Alan McKinnon wrote: >>> >>>> On 10/02/2013 17:29, covici@ccs.covici.com wrote: >>>>> I had to actually prevent the migration to /run by changing the >>>>> boot.misc script because if I do not do that, a number of subdirectories >>>>> which I had created in /var/run were not in /run and a number of apps >>>>> would not start properly and indeed it is not taking much space, so I am >>>>> not sure why anyone bothered. The only other option would have been to >>>>> write something to fix the /run, but that was not what I wanted to do. >>>>> /var/lock had this same problem also. >>>> >>>> Why would you do that? >>>> >>>> /var/run is broken as the destination folder for what is intended to go >>>> in it, and it has been broken since day 1: >>>> >>>> /var/run is only available once /var is available or mounted. >>>> The contents of /var/run are often needed before /var is mounted. >>>> /run is the correct place for this. >>>> >>>> Problems with the migration are solved using the mv command >>> >>> But when I let the migration happen -- which was something udev or >>> openrc did -- then certain things in my runlevels would not start >>> because subdirectories in /var/run which were needed were missing and >>> had t o have correct owners and permissions. /var/lock needed certain >>> subdirectories also such as news. Only way to get them to work under >>> /run would be to have a script to run after boot.misc which created all >>> the subdirectories and fixed all the owners and permissions which is a >>> lot more work -- and it would of course have to be done on each reboot. >>> >>> >> >> Are these init scripts from packages in the official tree, something you >> wrote yourself or some third-party package? >> >> In the first case, check if the problem persists (I bet it's fixed now) >> and file a bug report. >> >> In the second case, the best approach is to patch your scripts to use >> the `checkpath` command (see `man runscript`) to ensure that the >> expected paths exist. > > As far as I remember, these are all packages from the tree and I am > using unstable, so I would have to file a number of bug reports. > There are a few things such as freeswitch which I could fix in its > startup script, but here is the result of > find /var/run -type d > and I would also have to fix owners and permissions unless the package > maintainers fix things. > > /var/run/samba > /var/run/dbus > /var/run/named > /var/run/fail2ban > /var/run/asterisk > /var/run/freeswitch > /var/run/wpa_supplicant > /var/run/gdm > /var/run/gdm/greeter > /var/run/gdm/auth-for-gdm-GtotHP > /var/run/openldap > /var/run/dhcpcd > /var/run/dhcpcd/ntp.conf > /var/run/dhcpcd/resolv.conf > /var/run/pulse > /var/run/mysqld > /var/run/cups > /var/run/cups/certs > /var/run/radvd > /var/run/pm-utils > /var/run/pm-utils/locks > /var/run/pm-utils/pm-powersave > /var/run/pm-utils/pm-powersave/storage > /var/run/proftpd > /var/run/dhcp > /var/run/udisks > /var/run/spamd > /var/run/ConsoleKit > /var/run/console > - bind-mount the partition /var/run is on to somewhere so you can get at the real contents without another mount getting in the way - mv -i /var/run/* /run - rmdir /var/run - ln -sfn /run /var/run That's how you would do it manually. There was a migration step that did it for your automatically, but I forget when that was (a while ago?) If those simple steps cause things to break for you, then something is badly wrong with your system, as the about is exactly how symlinks are supposed to work on Unix, they should be transparent and break nothing. This must always work as /run is guaranteed to be available before /var/run and to go away later. The only underlying cause I can think of for your troubles is that the symlink was never created or you deleted it, more likely the latter (no offense, i call it as I see it) -- Alan McKinnon alan.mckinnon@gmail.com