# Actions or methods called on session timeout

**URL:** <https://forum.pydio.com/t/actions-or-methods-called-on-session-timeout/2691>\
**Category:** Development\
**Created:** [August 15, 2019, 1:54pm UTC](https://forum.pydio.com/t/actions-or-methods-called-on-session-timeout/2691 "2019-08-15T13:54:48Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kyle\_Tuck](https://yyz2.discourse-cdn.com/flex032/user_avatar/forum.pydio.com/kyle_tuck/32/988_2.png) [@Kyle\_Tuck](https://forum.pydio.com/u/Kyle_Tuck)\
**Post date:** [August 15, 2019, 1:54pm UTC](https://forum.pydio.com/t/actions-or-methods-called-on-session-timeout/2691/1 "2019-08-15T13:54:48Z")

</div>

I’ve spent a little time searching docs and code to find out what actions, plugins, or methods get called/triggered when the session times out. Any help narrowing this down would be appreciated.

Also, is there a list of actions somewhere in the dev docs? I see many in manifest files, but cannot seem to find a list of available actions.

---

<div class="post-metadata">

**Author:** ![zayn](https://avatars.discourse-cdn.com/v4/letter/z/a87d85/32.png) [@zayn](https://forum.pydio.com/u/zayn)\
**Post date:** [September 10, 2019, 7:42am UTC](https://forum.pydio.com/t/actions-or-methods-called-on-session-timeout/2691/2 "2019-09-10T07:42:30Z")

</div>

Hello @Kyle_Tuck,

To be sure you are referring to Pydio 8 and not Cells?

---

<div class="post-metadata">

**Author:** ![Kyle\_Tuck](https://yyz2.discourse-cdn.com/flex032/user_avatar/forum.pydio.com/kyle_tuck/32/988_2.png) [@Kyle\_Tuck](https://forum.pydio.com/u/Kyle_Tuck)\
**Post date:** [September 13, 2019, 1:03pm UTC](https://forum.pydio.com/t/actions-or-methods-called-on-session-timeout/2691/3 "2019-09-13T13:03:23Z")

</div>

It is Pydio 8. We are experiencing issues where file systems are not getting unmounted on session timeout. It is inconsistent though, so troubleshooting has been a pain. Added some additional logging into plugins/meta.mount/FilesystemMounter.php, but still haven’t found the issue. We have added a cron to unmount the shares. This seems to be the best (interim) solution.
