- Startup is the time between boot and the login screen. It's the habitat of system jobs.
- Login is the time after you enter your password. It's the habitat of user jobs.
The easy way to run a task at login is to run a script from your .bashrc.
And the (deceptively not-) easy way to run a task at logout is to run a script from your .bash_logout
But today we're not doing it the easy way. Today we're going to use dbus and Upstart.
Emitting Upstart Signals from your .bashrc
It's terribly easy.1) Emit a user-level Upstart signal by adding a line to .bashrc:
# Upstart signal that .bashrc is running initctl emit "I_AM_LOGGING_IN"
2) Add a user-level Upstart job to ~.config/upstart/ for one user, or to /usr/share/upstart/sessions/ for all users:
# /home/$USER/.config/upstart/login_test.conf description "login test" start on I_AM_LOGGING_IN # Start criteria exec /bin/date > /tmp/login_test # Do something
3) Open a new terminal window (to load the new .bashrc). When you open the window, the Upstart job creates the tempfile at /tmp/login_test.
Clean up: Restore your bashrc, and delete the sample Upstart job.
Can I emit system-level Upstart signals from .bashrc?
Not directly. The script runs as a user, not as root.You can use a secondary method of triggering system-level Upstart signals, like sending a Dbus signal, or manipulating a file, or connecting to a socket.
Can I emit Upstart signals from .bash_logout?
No.Using initctl emit in .bash_logout will merely result in an error. The user-level Upstart daemon seems to be terminated before .bash_logout is run. The command will return a cryptic "Rejected send message"error from PID 1 (system Upstart). Since .bash_logout is not running as root, it cannot emit system-level signals.
Also, GUI terminal programs do not not run .bash_logout, unless you specify compatibility (with a flag) when you start.
That easy way of doing login actions is still too hard
Boy, are you difficult to please.Okay, there is an even easier way, but it's more complicated to explain: Instead of .bashrc emitting an Upstart event, let Upstart listen for a dbus signal.
Here is an example of the dbus message that occurs when I login via SSH to a new session. This signal is emitted by systend-logind every time a new TTY, ssh, or X-based GUI login occurs.
The signal is not emitted when you are in a GUI environment and simply open a terminal window - that's not a login, that's a spawn of your already-existing GUI environment:
signal sender=:1.3 -> dest=(null destination) serial=497
path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager;
member=SessionNew
string "4"
object path "/org/freedesktop/login1/session/_34"
The important elements are the source, the "SessionNew" signal, and the path of the new session.
Aside, let's query systemd-logind to find if the login is to a TTY, X session, or SSH. logind has lots of useful information about each session:
$ dbus-send --system \
--dest=org.freedesktop.login1 \
--print-reply \
--type=method_call \
/org/freedesktop/login1/session/_34 \ # Path from the signal
org.freedesktop.DBus.Properties.Get \
string:org.freedesktop.login1.Session \
string:Service
method return sender=:1.3 -> dest=:1.211 reply_serial=2
variant string "sshd"
It's right. I did connect using ssh.
Now let's construct an Upstart job that runs when I login via a TTY, X Session, or SSH. We will use Upstart's built-in dbus listener.
# /home/$USER/.config/upstart/login_test.conf description "login test" start on dbus SIGNAL=SessionNew # Listen for the dbus Signal exec /bin/date > /tmp/login_test # Do something
- Now, whenever you login to a TTY, X session, or SSH session, the job will run.
- If your job needs to tell the difference between those sessions, you know how to find out using dbus.
- If *everybody* needs the job, place it in /usr/share/upstart/sessions/ instead of each user's .config/upstart/
What about super-easy logout jobs?
Logout jobs are harder, and generally not recommended. Not super-easy. They are hard because you can't guarantee they will run. Maybe the user will hold down the power button. Or use the "shutdown -h now" command. Or the power supply sent a message that the battery only has 60 seconds of life left. Or the user absolutely cannot miss that bus....Here's the dbus signal that systemd-logind emits when a TTY, X, or SSH user session ends:
signal sender=:1.21 -> dest=(null destination) serial=286 path=/org/freedesktop/Accounts/User1000; interface=org.freedesktop.Accounts.User; member=Changed
All this tells me is that User1000 now has a different number of sessions running. Maybe it's a login (yes, it emits the same signal upon login). Maybe it's a logout.
Sure, we can do a login-and-logout Upstart job...
# /home/$USER/.config/upstart/login_test.conf description "login and logout test" start on dbus SIGNAL=Changed INTERFACE=org.freedesktop.Accounts.User exec /bin/date > /tmp/login_test
...but then you need logic to figure out who logged in or logged out, and whether it's an event you care about. Certainly doable, but probably not worthwhile for most users.
In other words, if you want to backup-at-logout, you need to structure it as a backup-then-logout sequence. Logout is not an appropriate trigger to start the sequence...from the system's point of view.
But I really want to do a job a logout!
Okay, here's how to do a job when you log out of the GUI environment. Logging out is the trigger. This won't work for SSH or TTY sessions.The Upstart jobs /etc/init/lightdm.conf and/etc/init/gdm.conf emit a system-level "desktop-shutdown" signal when the X server is stopped. You can use that job as your start criteria.
# /etc/init/logoff_test.conf description "logout test" setuid some_username # Your script probably doesn't need to run as root start on stopping lightdm # Run *before* it is stopped exec /bin/date > /tmp/logoff_test
No comments:
Post a Comment