search

motis-project / motis

Intermodal Mobility Information System
https://motis-project.de
MIT License
196 stars 47 forks source link

motis generate tool gets stuck with wrong configurated date #438

Open 1Maxnet1 opened 6 months ago

1Maxnet1 commented 6 months ago

When I execute the motis generate tool with a generate-config.ini as following:

query_count=1
message_type=routing
start_type=pretrip
dest_type=station
routers=/nigiri
dataset.begin=20230212
import.paths=schedule-bw:/data/motis-bw/gtfs

the tool gets stuck and doesn't finish, even if its only one query to generate. The GTFS dataset is newer and therefore does not provide trips for such an old date. Additionally the config.ini to run the server is also set to TODAY, instead of the outdated date.

Not a big deal (for me), as I figured out what the problem was, but for your information and in case someone else has a similar problem, this issue can be the reference on how to fix it. Additionally it would be nice to have a error message, explaining the issue, instead of just getting stuck.

vkrause commented 6 months ago

Might be entirely unrelated but I also managed to produce an infinite loop (log output shows a continuous stream of operations between /lookup/geo_station and /ppr/route, ie. not a deadlock), on the Swiss national dataset when enabling car parking as one of the start modes. A single query between arbitrary coordinates is enough it seems, the only way to recover is killing the server then.

So hardening against that seems like a good idea indeed, although that might very well be easier said than done.

felixguendling commented 6 months ago

I guess those two problems are unrelated. The /lookup/geo_station <-> /ppr/route loop seems more critical as this can make denial of service attacks very easy (and cannot be prevented with a simple rate limiting proxy).

The motis generate problem is something I also hit, but it's easy to detect (query generation should take only a few seconds).

If someone feels like fixing it, those loops would require a breaking condition of maybe 10000 iterations until something like std::terminate is called after printing some helpful message.

https://github.com/motis-project/motis/blob/fa978f6efb3da418cb67d00ae3e6da865941bd8f/modules/intermodal/src/eval/generator/intermodal_generator.cc#L359-L368

https://github.com/motis-project/motis/blob/fa978f6efb3da418cb67d00ae3e6da865941bd8f/modules/intermodal/src/eval/generator/intermodal_generator.cc#L726-L735

https://github.com/motis-project/motis/blob/fa978f6efb3da418cb67d00ae3e6da865941bd8f/modules/intermodal/src/eval/generator/intermodal_generator.cc#L702-L704

I would prioritize fixing the infinite loop that can occur in production way higher than the developer support tooling.

vkrause commented 6 months ago

Thanks for the pointers, I'll see if I can break my loop with those.

felixguendling commented 6 months ago

Oops, I should not have mixed the issues. These loops are all in the motis generate command. For the loop you describe, I would need to have a debugger somewhere in motis_call to see who triggers those requests (and why):

https://github.com/motis-project/motis/blob/8b6cbecb4e31c7f89140fcc0602bbb20162cb58b/base/module/include/motis/module/context/motis_call.h#L12-L25