When the Centos will Shutdwon, reboot or logoff , I want to pop a Message Window.
I made the window by gtk, then how can i do?
Please forgive me my lousy English. :-(
You will need to write your program as a daemon, and use DBus to monitor signals from logind. Take a look at the PrepareForShutdown and PrepareForSleep signals; probably also one or more of the UserRemoved, SessionRemoved, SeatRemoved signals.
In order to pop up your dialog you will also need to set an inhibitor so that the system cannot shut down until your dialog box has been dismissed.
If you want to interrupt logging off or switching users, you will also need to set an inhibitor on org.gnome.SessionManager.
'Behind the scenes', in modern Linuxes, is a system which sends notifications to applications interested in them. Though I haven't used shutdown and similar events, I'm quite certain they are available too. This notification service is Window-manager independent, and works in both Gtk+ and Qt.
Even though CentOS isn't mentioned in this list, there should be ample information in the links provided. Lower down the page is a reference to libnotify, which is the toolbox for C. Many others are mentioned.
Related
Sorry if I'm using wrong terminology here.
I'd like to make an appliance for users that's running from a Raspberry Pi. When it's booted, I'd like users to see my own GUI that I'll design (hopefully in PyQT but I'm not sure about that yet.)
The thing I don't know how to do: I don't want the users to see the Linux operating system on the screen at all. I don't want them to see the desktop and launch my app. I want my app to be automatically launched on startup. I want it to be the only thing accessible and visible to the users. i.e. it should be full-screen and a user wouldn't be able to exit it or interact with the OS in any way.
How can I do that?
I understand that in Linux a windowing system (X11, Wayland etc.) is responsible for rendering applications on the screen. I experimented with X11 but never got past obtaining single windows. I also read about Wayland. My question is, if I want to write an application that grabs whatever is shown on the screen, is there a way to get it on such a low-level (drm, dri, kms) that I am not dependent on the windowing system? What choices do these low-level APIs give me compared to the windowing system?
EDIT: I realized reading this that "One of the features of Wayland is its security design, which helps to guard the user against malicious apps. Apps can no longer see everything on the screen and spy on you. But that also means you cannot run a common application (like shutter or gtk-recordmydesktop) and use it to make a screenshot or a screencast of your desktop".
Just to preface I'm not looking for specifics on what caused my particular systems instability - just seeking to understand how it could be possible since in my mind there are a multitude of layers between a function being called in response to a browser responding to a mouse click and whatever is at the hardware level that could cause an instant hardware reboot (no 'the system is shutting down' or any such).
Just to give some context, just before my system rebooted to write this I had 12 tabs open on Firefox on Mint Linux - one of those was a youtube page video. I swapped to another to check something clicked on the following url in a link (http://kripken.github.io/mloc_emscripten_talk/#/) - a slide-show which causes no ill effects now that I'm visiting it. But the instant I clicked the link BAM all lights out on a laptop with full battery and power cord connected.
So my question is what sort of error could spill over between an application running in user space and whatever space that is required to take down the entire system?
Lot many times userspace processes , would access kernel via system call interfaces.
For ex, playing video can use system calls related to video interfaces.
Suppose these interfaces has got a bug ( which can be driver specific) , then there is obvious chances of it to reboot the system
How can I restrict keyboard shortcut options in x11vnc?
for example, I want to restrict Alt+F4, Alt+x, Ctrl+Q, etc.
Is -skip_keycodes option of any help here?
You can probably configure such shortcuts in your window manager. That way, such shortcuts won't be passed to the application, and you should be able to handle them.
But, since you seem to want an application running all the time (you want to prevent users from closing it), then it might be a good idea to write a simple script like this:
while true; do run_your_application ; done
That way, if the application crashes or is closed, it is restarted. (be careful about applications that fork themselves or detach from the terminal!)
On the other hand, if you just want a browser, you can try using the kiosk mode from Opera browser. See also kiosk software at Wikipedia.
Update: So you are using Gnome... I don't use Gnome, but a quick search at SuperUser gave me this answer:
https://superuser.com/questions/132666/how-to-disable-control-alt-arrow-gnome-window-manager-control-for-redhat-linux
[…] all the keyboard shortcuts gnome uses are under System, Preferences, Keyboard shortcuts.
But... Are you sure you want a Gnome environment running there? Do you really want users to be able to run and configure anything from your Gnome interface? Maybe you would prefer another more minimalistic Window Manager. Which one? I'm not sure, must look what are the alternatives and try some of them. Depending on the application, it might even be possible to run it with no window manager at all.
I don't what kind of problem you are trying to solve, but maybe using a VNC applet in a webpage in order to have access to one application might not be the best solution. Of course, it depends on what is the problem and who are the users.
A linux machine freezes few hours after booting and running software (including custom drivers). I'm looking a method to debug such problem. Recently, there has been significant progress in Linux Kernel debugging techniques, hasn't it?
I kindly ask to share some experience on the topic.
If you can reproduce the problem inside a VM, there is indeed a fairly new (AFAIK) technique which might be useful: debugging the virtual machine from the host machine it runs on.
See for example this:
Debugging Linux Kernel in VMWare with Windows host
VMware Workstation 7 also enables a powerful technique that lets you record system execution deterministically and then replay it as desired, even backwards. So as soon as the system crashes you can go backwards and see what was happening then (and even try changing something and see if it still crashes). IIRC I read somewhere you can't do this and debug the kernel using VMware/gdb at the same time.
Obviously, you need a VMM for this. I don't know what VMM's other than VMware's VMM family support this, and I don't know if any free VMware versions support this. Likely not; one can't really expect a commercial company to give away everything for free. The trial version is 30 days.
If your custom drivers are for hardware inside the machine, then I suppose this probably won't work.
SystemTap seems to be to Linux what Dtrace is to Solaris .. however I find it rather hostile to use. Still, you may want to give it a try. NB: compile the kernel with debug info and spend some time with the kernel instrumentation hooks.
This is why so many are still using printk() after empirically narrowing a bug down to a specific module.
I'm not recommending it, just pointing out that it exists. I may not be smart enough to appreciate some underlying beauty .. I just write drivers for odd devices.
There are many and varied techniques depending on the sort of problems you want to debug. In your case the first question is "is the system really frozen?". You can enable the magic sysrq key and examine the system state at freeze and go from there.
Probably the most directly powerful method is to enable the kernel debugger and connect to it via a serial cable.
One option is to use Kprobes. A quick search on google will show you all the information you need. It isn't particularly hard to use. Kprobes was created by IBM I believe as a solution for kernel debugging. It is essentially a elaborate form of printk() however it allows you to handle any "breakpoints" you insert using handlers. It may be what you are looking for. All you need to do is write and 'insmod' a module into the kernel which will handle any "breakpoints" hit that you specify in the module.
Hope that can be a useful option...
How I debug this kind of bug, was to run my OS inside the VirtualBox, and compile the kernel with kgdb builtin. Then I setup a serial console on the VirtualBox so that I can gdb to the kernel inside the VirtualBox's OS via the serial console. Anytime the OS hang, just like magic sysrq key, I can enter ctrl-c on the gdb to stop and understand the kernel at that point in time.
Normally kernel stack tracing is just too difficult to pinpoint the culprit process, so the best way I think is still generic "top" command, just looking at the application logs to see what are the cause of hanging - this will need a reboot to see the log of course.