Opened 12 years ago

Closed 12 years ago

#5269 closed defect (fixed)

Race condition in mythshutdown

Reported by: anonymous Owned by: paulh
Priority: minor Milestone: 0.21.1
Component: mythshutdown Version: 0.21-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

It looks like there may be a race condition in mythshutdown because the fetch and the update for the increment and decrement are done as as two different statements instead of a single atomic operation or being wrapped in a transaction to ensure consistency. The window is relatively narrow but since there are multiple system calls involved rescheduling is very possible. The issue here is that you don't get reliable reversability with multiple callers as was clearly intended. It's possible to have a sequence of --lock or --unlock operations leave the system in either state because they could be working on stale data

For example consider the following interleaved sequence:

Script A runs "mythshutdown -l" mythshutdown A fetches 0 Script B runs "mythshutdown -l" mythshutdown B also fetches 0 mythshutdown A stores 1 mythshutdown B stores 1

The correct value should have been 2, and because it's not, the first script that runs "mythshutdown -u" will unlock for both and leave the other caller unprotected. The same type of thing can end up with interleaved unlocks leaving the system locked when it should be unlocked.

Change History (3)

comment:1 Changed 12 years ago by paulh

Milestone: unknown0.21.1
Owner: changed from Isaac Richards to paulh
Status: newaccepted

comment:2 Changed 12 years ago by paulh

(In [17342]) Fix a possible problem with mythshutdown --lock/--unlock.

The lock/unlock commands can be nested so if lock is called twice unlock would have to also be called twice to unlock shutdown. Each lock/unlock requires 2 db queries one to get the setting and one to save it back again. The problem is if two instances of mythshutdown is running the reads and writes could overlap each other resulting in the setting getting out of sequence.

This fixes the problem by using only one query to update the setting and also locks the table making it impossible for two mythshutdown processes to update the lock setting at the same time.

Refs #5269.

comment:3 Changed 12 years ago by paulh

Resolution: fixed
Status: acceptedclosed

(In [17343]) Merge r17342 from trunk.

Fix a possible problem with mythshutdown --lock/--unlock.

The lock/unlock commands can be nested so if lock is called twice unlock would have to also be called twice to unlock shutdown. Each lock/unlock requires 2 db queries one to get the setting and one to save it back again. The problem is if two instances of mythshutdown is running the reads and writes could overlap each other resulting in the setting getting out of sequence.

This fixes the problem by using only one query to update the setting and also locks the table making it impossible for two mythshutdown processes to update the lock setting at the same time.

Fixes #5269.

Note: See TracTickets for help on using tickets.