Re: [DNG] Remote power management
On Thu, 22 Jul 2021 10:10:16 +0100, fraser wrote in message <20210722101016.5370801b@bay6-hi5-1>: > Hi, > > This feels like a damnfool question, but I don't seem able to find an > appropriate solution. > > The situation: careless staff leaving desktops logged on, open tabs in > browsers, monitors left on etc.etc. > > First solution: cron job: '/sbin/shutdown -r now' run daily at 7pm ..and not e.g. '/sbin/shutdown -h -P "19:00 Shutdown at 7:00 pm!" ' in the morning? Would give your careless ones due warnings they may heed or not at their own peril... man shutdown for details. > But this reboots to a live console login (no dm installed) and I > haven't yet found a way to remotely configure the power management; > all the solutions seem to merge to one where X is already running (or > eliminating human error!). > > The situation is complicated by the need to subsequently disable power > management and screensaver so that online video (tutoring) doesn't get > interrupted once X and xfce are manually launched. So here is my > damnfool question: > > How can I manually turn any monitors off remotely if they are not > running X? The computers are all running Chimaera. ..ssh in and chk, then kill etc as needed. Can be automated, just needs ssh servers on all boxes, and some cronjob magic ambitions. > Sorry for such an elementary question, but it's eluded me. ..if you control the building power, follow up your First solution by cutting power at say 7:00:30pm, to kill off the rebooting desktops. Dirty, yeah. ;o) Just restore building power the next mornings to have your careful desktop riders welcome their live console logins. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Nasty Linux systemd security bug revealed
Hi, On Thu, Jul 22, 2021 at 07:53:58AM +0200, Didier Kryn wrote: > There's a choice of options in GCC to deal with stack protection. > Eg: -fstack-check > > Plus a bunch of macros. > > They all deal with allocation of automatic variables. For alloca(), > instead, there's explicitely no check. I don't find any reference about automatic variables in the docs regarding this topic. Actually, the description of gcc's alloca() builtin states that it behaves similar to automatic variables. However, all these macros will not prevent you from stack overflow but only help you to detect one when it already happened. Also, the way gcc implements the check (probing SP) works for alloca and for automatic variables in the same way. However, once you have detected a stack overflow, your application is in an inconsistent state. Of course you can implement some kind of rescue. (e.g using libsigsev) But you have to do a clean rewind of your app state back to state before the overflow occurred. This can become quite complex and hard to maintain. And then your're back to state before stack overflow, but what is the application supposed to do then? Log and ignore the request? Terminate? Ask the User? The point is, an application should be designed such that a stack overflow just can not occur. And this implies length checking, regardless if using automatic vars or alloca. > In addition, the compiler is not informed of the invocation of > alloca(); therefore the space allocated to non-static automatic > variables may overlap with the space "allocated" by alloca(). No. This is wrong alloca() is implemented as compiler builtin and does exactly the same as GCC does when allocating automatic vars on the stack. Prove: https://godbolt.org/z/abqK4T43c The generated machine code is identical including the stack overflow checking code. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Remote power management
hi, try vbetool vbetool dpms off regards, m. On 210722, fraser kendall wrote: Hi, This feels like a damnfool question, but I don't seem able to find an appropriate solution. The situation: careless staff leaving desktops logged on, open tabs in browsers, monitors left on etc.etc. First solution: cron job: '/sbin/shutdown -r now' run daily at 7pm But this reboots to a live console login (no dm installed) and I haven't yet found a way to remotely configure the power management; all the solutions seem to merge to one where X is already running (or eliminating human error!). The situation is complicated by the need to subsequently disable power management and screensaver so that online video (tutoring) doesn't get interrupted once X and xfce are manually launched. So here is my damnfool question: How can I manually turn any monitors off remotely if they are not running X? The computers are all running Chimaera. Sorry for such an elementary question, but it's eluded me. fraser ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Remote power management
On Thu, 22 Jul 2021 10:10:16 +0100 fraser kendall wrote: > Hi, > > This feels like a damnfool question, but I don't seem able to find an > appropriate solution. > > The situation: careless staff leaving desktops logged on, open tabs in > browsers, monitors left on etc.etc. > > First solution: cron job: '/sbin/shutdown -r now' run daily at 7pm > > But this reboots to a live console login (no dm installed) and I > haven't yet found a way to remotely configure the power management; all > the solutions seem to merge to one where X is already running (or > eliminating human error!). > > The situation is complicated by the need to subsequently disable power > management and screensaver so that online video (tutoring) doesn't get > interrupted once X and xfce are manually launched. So here is my > damnfool question: > > How can I manually turn any monitors off remotely if they are not > running X? The computers are all running Chimaera. > > Sorry for such an elementary question, but it's eluded me. > > fraser > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Hi, something like (at the end of startx?): #export DISPLAY=:0.0 (should be set) # turn off xset -display $DISPLAY dpms force off # read keyboard input read dummy # turn on again if keyboard active xset -display $DISPLAY dpms force on Untested. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Remote power management
Hi, This feels like a damnfool question, but I don't seem able to find an appropriate solution. The situation: careless staff leaving desktops logged on, open tabs in browsers, monitors left on etc.etc. First solution: cron job: '/sbin/shutdown -r now' run daily at 7pm But this reboots to a live console login (no dm installed) and I haven't yet found a way to remotely configure the power management; all the solutions seem to merge to one where X is already running (or eliminating human error!). The situation is complicated by the need to subsequently disable power management and screensaver so that online video (tutoring) doesn't get interrupted once X and xfce are manually launched. So here is my damnfool question: How can I manually turn any monitors off remotely if they are not running X? The computers are all running Chimaera. Sorry for such an elementary question, but it's eluded me. fraser ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
