From owner-freebsd-questions@freebsd.org Wed Apr 20 00:20:35 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7ADC5B15CF7 for ; Wed, 20 Apr 2016 00:20:35 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3389619DA for ; Wed, 20 Apr 2016 00:20:34 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u3K0KXwW006072 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Apr 2016 18:20:33 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u3K0KX6a006069; Tue, 19 Apr 2016 18:20:33 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 19 Apr 2016 18:20:33 -0600 (MDT) From: Warren Block To: "Brandon J. Wandersee" cc: freebsd-questions@freebsd.org Subject: Re: Simple devd.conf rule has no effect In-Reply-To: <86bn552vga.fsf@WorkBox.Home> Message-ID: References: <86fuuywldn.fsf@WorkBox.Home> <86bn552vga.fsf@WorkBox.Home> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 19 Apr 2016 18:20:33 -0600 (MDT) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 00:20:35 -0000 On Tue, 19 Apr 2016, Brandon J. Wandersee wrote: > > Warren Block writes: > >> On Wed, 6 Apr 2016, Brandon J. Wandersee wrote: >> >>> >>> Hi, folks. I'm trying to get my laptop screen to lock when the lid >>> closes, using x11/slock. I've created the file /etc/devd/lidlock.conf >>> with the following rule: >>> >>> | notify 0 { >>> | match "system" "ACPI"; >>> | match "subsystem" "Lid"; >>> | match "notify" "0x00"; >>> | action "/usr/local/bin/slock"; >>> | }; >>> >>> This is really just a slight variation on the example from the >>> devd.conf(5) man page. Now when I close the lid, the screen fails to >>> lock, yet /var/log/messages displays the message "devd: Executing >>> 'slock'". Any advice on what to look into to figure out why the program >>> is not actually executed? Thanks in advace. >> >> devd(8) stuff runs as root, I think. So it probably does not have >> $DISPLAY set. Maybe use su to switch to the normal X user and execute >> the command: >> >> su -l xusername -c 'setenv DISPLAY :0.0 && /usr/local/bin/slock' > > Thanks for the response, Warren; sorry for the lateness of mine. Your > solution works when run from a shell, but devd still doesn't properly > execute it. I also tried changing the quotes around, adapting it for my > user shell (changing 'setenv' to 'export DISPLAY='), and putting it in a > shell script and executing the script from the devd config file. No > luck. Guess I'll just keep messing with it when the mood strikes, see if > anything clicks. This was actually a good time for a reply, as I needed to set up something similar. The idea was to run xlock before suspending so text on the screen is not visible when it wakes up. This, based on your example, finally worked: notify 20 { match "system" "ACPI"; match "subsystem" "Lid"; match "notify" "0x00"; action "/usr/bin/su wblock -c '/usr/local/bin/xlock -display :0.0 -mode qix & /bin/sleep 2'"' action "acpiconf -s3"; }; Running xlock as my unprivileged user might not be necessary, but seems safer. The 'sleep 2' might not be required, either, but it didn't want to work correctly until I did that. More experimentation is needed. The second action runs as root to suspend the machine. There is /etc/rc.suspend, but X already seemed to be stopped by the time that executed. Or something prevented running xlock from in there.