Hello everyone .
thanks for reading me .
i’m wondering where is the .pid file
despite the .conf file giving a directory , i can’t find the file in this location .
i’ve tried to sudo make visible invisible files, but no. success .
so i was wondering if i missed something
thx for helping out
cheers
Hi Guillaume, the pid file should be written to the ‘logPath’ specified in the config file. If that’s not the case you might want to confirm that you’re not running the shotgun event daemon in foreground mode (in which case no pid file is generated). I’d also recommend checking write permissions on the log path in questions, even though presumably you’re running the daemon as root.
Hello Nico . thanks alot for your feedback . i’m definitely running the Deamon in foreground mode . as i’m developping plugins, i love to see the logger talking to me .
i’m pretty sure that not that long ago, even in foreground , i had access to pid files . but perhaps not .
anyway
i’m looking for a way to launch the event process loop , giving a special event id to my plugin .
i used to do it ( i think) via the pid file, or a file that listed the plugins running and in front of each , the event id last processed .
it was pretty simple to go to that file, and change the number manually .
if you or anyone could show me a lead on how to perform that , that would be super nice .
cheers
G
HI Guillaume, I think you’re confusing the .pid and the .id file. The former is used to store the process id when the event deamon is running as an actual daemon (as opposed to foreground). The latter stores the last event id processed per plugin, and should always be found in the log directory regardless of whether you’re running in foreground mode. I think I actually steered you wrong before regarding the config; It seems these files are only stored in the logpath by convention, but there’s dedicated config settings to specify their location totally independent of the ‘logPath’ setting:
# processed event. This will allow the daemon to pick up where it left off when
# last shutdown thus not missing any events. If you want to ignore any events
# since last daemon shutdown, remove this file before daemon startup and the
# daemon will process only new events created after startup.
eventIdFile: /var/log/shotgunEventDaemon/shotgunEventDaemon.id
You might want to check the ‘eventIdFile’ setting in your config to confirm.
Cheers
Hello again .
i had a chance to look a this a bit closer, and i’m very surprised that the shotgunEventDaemon.id is not “readable” by any text editor .
i think i remember a time where all the plugins had the last event processed stored in this doc . and i was able to change the last event processed number to go back a bit in the loop .
now it seems to be only “bytes”
anyway, would you know by any chance a way to indicate the event process loop where to go back to start ?
thanks a lot .
@Guillaume_Dété have you found an answer to whether you can manually update the shotgunEventDaemon.id?
A small hack to get the event daemon to work for an earlier id:
Go into the shotgunEventDaemon.py file and find the line where lastEventId is set (line 454 for me). This is where it creates a new id file using the latest event from SG, in the case that the id file is missing.
Change that line to be lastEventId = 1234567 (using the event id you want to start with), delete the shotgunEventDaemon.id file, and start the service. It’ll use that number to create a new shotgunEventDaemon.id file.
Remember to change the code back to the original after a new id file is created.
If you force open that file with a text/code editor you will see its simply a text file with a number.
No code alterations needed here.
Which file? shotgunEventDaemon.id? That file is no longer a text number. it’s binary.
The shotgunEventDaemon.py code does seem to indicate that it will look for a number in the file, but when I tested, it didn’t pick it up, and I didn’t have time to look into it further.
Oh thats strange.
Maybe thats a bug with python 3 conversion?
