Getting Help¶
Request Tracker is Sysnet’s help request system used for tracking issues related to network, computer, services, or any IT related problem or question in Oden Institute. All staff members in Sysnet monitor requests as they come by, it is important to use RT when requesting help and avoid reaching out to an individual member of Sysnet.
How to reach Sysnet¶
You will see the following email link on many help pages, RT .
How to write good support requests¶
This body of text was inspired by other organizational units in the HPC realm, TRECIS and UiT. We’ve tailored it to our environment.
Writing good support requests is not only good for Sysnet, it is also better for you! We receive many help requests on a daily basis, we also have other projects we’re working on, so our time is precious. The easier it is for us to understand your problem, the faster we will get to it. Below is a list of good practices.
Provide basic information about the host, network, and you¶
Provide us the hostname for the desktop or the server you’re having issue with. We attempt to affix a label with the DNS hostname on the front of the workstation. If it’s missing a label, we need to know. Don’t see the hostname? Open a terminal and issue ‘hostname’.
What is your Oden Institute user name? You’re EID is helpful in some cases.
If you’re having a network issue, provide us information about the port you are connected to, include the outlet or ACO information, usually a 3 or 4 digit number followed by a ‘D’. If you’re on the wireless, let us know that too.
If you’re using a UT owned laptop or tablet, provide us a UT tag number often on the back of the device.
Provide a room number in the event we need to come to you.
If it’s a printer, provide the printer name. Printers should be labeled with a designation like pr6330 or cp5126, where the digits represent the room number. If it’s missing a label or is incorrect, we need to know!
Providing as much information about your physical environment as possible helps avoid us peppering you with questions.
Never send support requests to staff members directly¶
Always send a help request to RT and the Sysnet team will pick them up there. Sending the request to RT makes sure that one of us will see it. Emailing any Sysnet team member directly just slows the process down, we’ll kindly ask you to submit the help request or simply ignore it!
Do not manhandle us as simple as Let me Google that for you assistants¶
Yes, sometimes we feel like we’re just Google assistants. However, most problems at the institute don’t really fit into this category. If you find that you cannot find the answer on Google or you don’t think your problem can be solved by Google, keep reading this thread.
Provide a descriptive subject¶
Your subject line should be descriptive, Problem on katrina is vague. It makes it difficult to search for the issue.
Include actual commands and error messages¶
When submitting help requests, please include the commands you run as well as any error messages you receive. Please copy and paste these into the email/ticket. If you fail to do so, we will likely be annoyed and request this information.
Please refrain from submitting screenshots or pictures (JPEG, PNG, etc…) of what you see on your terminal screen. Not everyone views emails using a graphical email client and doing this slows us down while trying to research your issue. We don’t care what your ticket “looks” like. We just need the relevant text copy/pasted into the email/ticket so we can quickly and easily research your problem.
Create a new ticket for a new issue¶
Replying to an open ticket with an unrelated issue slows everything down and causes more confusion. The help request system is a historical database, we regularly use it to search back on older issues to help in resolving a new issues.
The XY problem¶
Quoting from The XY Problem:
User wants to do X.
User doesn't know how to do X, but thinks they can fumble their way
to a solution if they can just manage to do Y.
User doesn't know how to do Y either.
User asks for help with Y.
Others try to help user with Y, but are confused because Y seems
like a strange problem to want to solve.
After much interaction and wasted time, it finally becomes clear
that the user really wants help with X, and that Y wasn't even a
suitable solution for X.
Please avoid the XY problem. If you’re having issues with Y but are trying to do X, please tell us about X. Tell us exactly what you are trying to do. Occasionally, solving Y can take a long time while solving for X is simpler.
Provide relevant information about what works¶
If you are submitting a request because your issue only manifests in certain situations, let us know. It’s helpful for us to know if your problem exists all the time or if it’s only present under specific conditions. Providing us with more information will make it easier to isolate the issue and avoid long email threads where we have to ask many questions. Let us know what steps you’ve taken to try and isolate the issue so that we can quickly provide assistance.
Tell us about your environment¶
What code are you attempting run? Is it custom? If so, where is this located? Is it using one of our modules? It is? What modules are you loading. Wait, did you update your .bashrc or touch it, you might look there.
What we’re driving at here is pretty simple, you should provide us as much information about your environment as possible, this includes if you’re running conda, jupyter, etc…
Simple cases: Be specific, include commands and errors¶
Simply saying “X didn’t work” will not result in us solving your issue. Please provide the exact commands run, the environment, the output and error messages. Providing us with the actual error messages is extremely useful. It allows us to easily copy and paste it while researching your issue. The better you describe the problem the less we have to guess and ask.
Occasionally seeing the actual error message is enough to provide a useful answer. In almost every case, you will need to make sure the problem is reproducible and provide us with a way to reproduce.
Complex cases: Create an example which reproduces the problem¶
For complex issues, please create an example that we can copy, paste and run which demonstrates the problem. It’s too time-consuming for our team to try and debug your issue based on incomplete information. Please also see below.
Make the example as small and fast as possible¶
If you are running a calculation which crashes periodically, you will need to reduce the example running time. Your goal should be to get the example as small as possible while still demonstrating the issue.
It will be easier for us to debug an issue that crashes within a few seconds than one which has a log time measured in minutes or hours. Yes, this requires some effort on your part but it will pay off with a support request that we can answer quickly and effectively.