Setting the gc_maxlifetime to a small value does not have an effect on the functioning of your forced logout in the way you expect.
There is a common problem with this. On shared hosting and you are using the default session.save_path (on shared hosting you should set this to be within your own web space to avoid this problem) and all the session files are in one location, the shortest session.gc_maxlifetime is used. If someone else is using a longer session.cookie_lifetime and the garbage collection occurs, their session files will be deleted and they and their users will wonder why their sessions were canceled.
Note, based on direct repeatable observation, at least on Windows based PHP hosting, and I suspect on all PHP hosting, if someone is viewing a web page that is using sessions and he keeps the page open longer then the gc_maxlifetime (takes a long time to fill out a form or goes on a break) and it is a busy web server (counting all sites/domains using sessions) so that enough sessions are opened so that garbage collection occurs, the session files that are old enough will be unconditionally deleted. When this occurs the session no longer exists and anyone in the middle of a session that was deleted will receive an unexpected surprise.
Garbage collection was assumed (ASSUME = make an A**-out-of-U-and-ME) to work by only running every N sessions (N = session.gc_probability/session.gc_divisor)(despite the name probability, no randomness is involved, this is strictly a COUNTER) and it was ASSUMED that any session files older than session.gc_maxlifetime were safe to delete (there is no flagging or locking to insure that files for open sessions are not deleted. The session files are only accessed when they are created/read at the start of the session and are written to when you create a new session variable and when the session ends.) On a busy server the values for these should actually be increased.