Hi to all.
My first message here, but i following you via twitter feed from many time...
The question:
I need to delay 5-10 seconds the shutdown command executed when the user click on the power off/reboot in their session or at login screen.
I need that because i have in the background a process that need to comunicate with a remote MySQL server login or logout of the users. In the normal case the shutdown process bring the network interface down before the local script can set a new logout record on DB.
I don't know what gnome execute when system is halted o rebooted.
I have tried this solution:
mv /sbin/shutdown /sbin/shutdown.bin
How is your background process started, and how do you signal it to log out? Maybe a service script in /etc/init.d (with appropriate entries in the required runlevel(s)) would solve your problem better than tinkering with shutdown .
I'm not that fit with upstart, but as far as I know the MySQL startup script can be made a dependency of your script. I think (but not sure) that the line should be something like this:
start on net-device-up IFACE=eth0 #example
stop on runlevel [01S6]
This should start your script as soon as the network interface becomes available, and stop it when the system starts to shutdown/reboot.
ok,
currently don't have declared any stop @ runlevel for this process.
The script must have the time to intercept the disconnection of 'user, which normally happens at shutdown.
At this point we think we need to play with the times, allowing the script to understand that the 'user is no longer connected and communicate to the MySQL server, the first turning off or disable the' network interface
Remember, the script generates a loop that repeats every three seconds to 'inside of which are recognized as the users who are connected or disconnected .. and communicates with mysql..
The purpose of running strace on gnome is to show you all the components that run, signal, write to get to the shutdown, places where you could definitely intercept the process and hold it up while the DB update occurs (unless you figure a way to not need the db update).
the question is: what i have to put in strace for debug gnome shutdown process?
I don't understend why if replace the original /sbin/shutdown with a wrapper that insert a delay first then execute /sbin/shutdown.bin (original executable) don't work...
You might need options for following forks and threads, arguments and environment, if it is like truss and tusc. I'd look at the man page through the link above, but I have no LINUX most days lately.
You can usually trace running processes with a pid, and maybe an option, maybe last. It requires your be root or the process owner, and gets scraped off by setuid/sergid exec().
Sorry if I'm interrupting, but why should anyone want to trace and/or modify the way GNOME behaves for an issue like this. GNOME will probably signal init directly, just like shutdown, but without calling the shutdown binary. So the most sensible way, since the script is already started by init, would be to stop it using init too.
You might consider a stateful local intermediate demon that takes your logout loggin request and stores it, then fulfills it as soon as the database is available. Of course, this does not give immediate status, but does ensure accurate history, so it is a matter of priorities.
I still suspect there is a log of connections made and lost in most RDBMS that makes your table redundant. It might be a flat file you could frequently sync your table to. Then, it is accurate even if the client machine is crashed or power of net drops suddenly. Not only is this sufficient, it might be necessary!
the script don't have a continuous connection to the DB but make connection only when events occur (login/logout)
I have a flat file for debugging but i think that if the script run when system going down can't recognize the user logout...that's why want to simple make a delay between logout and shutdown...
Sometimes stuff is hard to do because everyone else discovered you should not do it that way!
I am just trying to get a handle on what you are monitoring with your sql rows. The monitoring of clients is better done on the server, as clients can have problems saying "I am broke, gone" because they are broke or gone. Servers can tell if connections are broken, but web apps do not need continuous connection. Even tcp connections are not that good an indication, with all the keep-alive faking on the networks to reduce congestion. An application level keep-alive heartbeat is sometimes necessary for real monitoring.
The purpose of monitoring may be status (is everyone on?) or history (has everyone been on 8 hours 5 days this week?, How many are on, on average>).
This is a bit like removing the appendix through the left nostril -- limited perception or available action!
