Ok, as you'll see if you search about you really want to avoid shrinking log files as they generally only grow again at a cost to performance.
Try to give us more specifics about your particular problem, is the log file 10x bigger than the data file by any chance?
For a runaway t-log shrinking may be a sensible option as long as you bear in mind
1/ ensure you leave the file large enough to handle the transaction load on that database.
2/ ideally shrink it out of hours especially if it's extremely large
3/ cure the problem first that caused the log to runaway in the first place, generally a database in full recovery with no regular t-log backups taken against the database.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉