Post #441,666
6/15/22 3:30:08 PM
6/15/22 4:32:48 PM
|
Don't care on the politics or development trends and history
Do you want to fix it?
I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.
You want to follow forks because the main process can spawn children process before it gets to the point of actually reading your file. So you want to watch everything until you figure out that you don't need to follow forks because you're just getting too much damn information.
Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.
If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.
Everything I described above can be accomplished in about three scripts with two or three lines apiece. A couple of pipes assigned into a variable. I'd probably put them in 10 line Perl scripts so I would have added instrumentation and logging for the script itself. But you're not going to be doing this.
Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.
That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.
Using this method, you can see when a vendor is attempting to open up a series of cascading files and failing to handle errors. They just didn't bother checking the code that was returned.
Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.
There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.
Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.
Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.
I've used the words redirect and pipes. If you do not know how to use multiple '|' and then finally '>' and '2>&1' and backticks and variable assignment in a script then maybe you are part of the desktop Linux generation that should go back to something else.
But if you do understand these things then you can do pretty much anything on a Linux system.
I've given up believing Linux systems will ever be general purpose desktops. But for experts willing to learn, they're amazing.
And this is not an insult to you. This s*** is complex. This s*** is crazy cascading problems sometimes. You have to do a cost-benefit analysis if it is worth it. No vendor has ever created a desktop Linux system that I'm aware of that doesn't frustrate people enough that they say screw this, I don't need it. It just takes way too much work for way too limited a marketplace. I don't even know if it's actually possible.
So you got windows and Apple. Apple is a Unix-based environment to start off with and it's got the vast majority of tools that the Linux system does. So as far as I'm concerned, that should be an easy move. Windows has many add-ons that will emulate any Linux tools that you might want for the most part. So as far as I'm concerned, there's no shame in just saying screw it and using one of those.
Edited by crazy
June 15, 2022, 03:51:51 PM EDT
Don't care on the politics or development trends and history
Do you want to fix it?
I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.
Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.
Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.
That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.
Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.
There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.
Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.
Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.
Edited by crazy
June 15, 2022, 03:52:52 PM EDT
Don't care on the politics or development trends and history
Do you want to fix it?
I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.
Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.
If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.
Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.
That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.
Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.
There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.
Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.
Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.
Edited by crazy
June 15, 2022, 04:13:27 PM EDT
Don't care on the politics or development trends and history
Do you want to fix it?
I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.
You want to follow forks because the main process can spawn children process before it gets to the point of actually reading your file. So you want to watch everything until you figure out that you don't need to follow forks because you're just getting too much damn information.
Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.
If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.
Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.
That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.
Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.
There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.
Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.
Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.
Edited by crazy
June 15, 2022, 04:23:18 PM EDT
Don't care on the politics or development trends and history
Do you want to fix it?
I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.
You want to follow forks because the main process can spawn children process before it gets to the point of actually reading your file. So you want to watch everything until you figure out that you don't need to follow forks because you're just getting too much damn information.
Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.
If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.
Everything I described above can be accomplished in about three scripts with two or three lines apiece. A couple of pipes assigned into a variable. I'd probably put them in 10 line Perl scripts so I would have added instrumentation and logging for the script itself. But you're not going to be doing this.
Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.
That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.
Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.
There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.
Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.
Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.
Edited by crazy
June 15, 2022, 04:26:37 PM EDT
Don't care on the politics or development trends and history
Do you want to fix it?
I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.
You want to follow forks because the main process can spawn children process before it gets to the point of actually reading your file. So you want to watch everything until you figure out that you don't need to follow forks because you're just getting too much damn information.
Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.
If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.
Everything I described above can be accomplished in about three scripts with two or three lines apiece. A couple of pipes assigned into a variable. I'd probably put them in 10 line Perl scripts so I would have added instrumentation and logging for the script itself. But you're not going to be doing this.
Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.
That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.
Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.
There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.
Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.
Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.
I've used the words redirect and pipes. If you do not know how to use multiple '|' and then finally '>' and '2>&1' and backticks and variable assignment in a script then maybe you are part of the desktop Linux generation that should go back to something else.
But if you do understand these things then you can do pretty much anything on a Linux system.
I've given up believing Linux systems will ever be general purpose desktops. But for experts willing to learn, they're amazing.
Edited by crazy
June 15, 2022, 04:32:48 PM EDT
Don't care on the politics or development trends and history
Do you want to fix it?
I haven't done this in over 10 years so I'm making this up as I go along but this is pretty much how you cure any problem when setting up or running a Linux system.
You want to follow forks because the main process can spawn children process before it gets to the point of actually reading your file. So you want to watch everything until you figure out that you don't need to follow forks because you're just getting too much damn information.
Number one: figure out the process ID of the parent process that launches everything else and set up some instrumentation somewhere that will launch it via strace or it pauses until signal so you get a chance to attach to it. There are many ways to skin that particular cat, but that's the starting point to fix anything on system launch.
If you were at the point that you know the configuration file that it is reading but you don't know the actual command that is launching you can replace the configuration file with a named pipe. That will cause the process to halt. Then you can have an additional process scan the process table to figure out its process ID. Then you can have it continue to run by catting the real configuration file into that named pipe. That way you can be sure that when you test changes it's the changes that you just made and have strace follow it from that moment.
Everything I described above can be accomplished in about three scripts with two or three lines apiece. A couple of pipes assigned into a variable. I'd probably put them in 10 line Perl scripts so I would have added instrumentation and logging for the script itself. But you're not going to be doing this.
Number two: figure out strace and the kinds of arguments you might send it. Execute command lines and pipe it to more and watch the output. Then figure out how much output you can handle and how much you actually need.
That's where grep comes in. You could do it a dozen other ways. But simply in this case you are grepping for file or pipe or socket open calls. So let's just say open calls.
Using this method, you can see when a vendor is attempting to open up a series of cascading files and failing to handle errors. They just didn't bother checking the code that was returned.
Then combine that knowledge with the previous figuring step and redirect the output of strace to a log file. And you will figure out 99.9% of system administrator problems that way. And the next time you're standing behind a system administrator at work, while he's confused about something, you should suggest that he uses strace. Everything else is flying blind.
There are many cases when I had vendor installed software that was doing all kinds of stupid s*** and I could tell them that they were attempting to open up the wrong configuration file or the wrong output file or the wrong whatever. Their tech support called me for help. Simply because I ran strace on their process and they couldn't figure it out.
Who cares if 99.9% of the population can't handle this and therefore Linux will never go anywhere. At least on the desktop. The system administrators know how to use it.
Also, there are windows tools that do this and much much more so you can have the same level of instrumentation under Windows and figure stuff out when most other people are just flailing around.
I've used the words redirect and pipes. If you do not know how to use multiple '|' and then finally '>' and '2>&1' and backticks and variable assignment in a script then maybe you are part of the desktop Linux generation that should go back to something else.
But if you do understand these things then you can do pretty much anything on a Linux system.
I've given up believing Linux systems will ever be general purpose desktops. But for experts willing to learn, they're amazing.
|
Post #441,667
6/15/22 3:38:02 PM
6/15/22 4:02:38 PM
|
And yes, I didn't tell you how to skin it
To start off with I assume it actually has a name on the process table?
It's your display manager. I can't tell you off the top of my head what it is called, and you probably had a choice of display managers on install so you're going to have to figure that out.
You should find something within your process table via the PS command.
If not, open up a window with top and then open up a window running something heavily graphic. The process you ran should pop to the top of top. Along with the display manager and possibly multiple other processes. Work your way up the process tree with the parent processes to determine what the top level process is if you can. If not, you may need to monitor a bunch of different ones.
Hey box: I haven't thought about this stuff for 8 years. How am I doing? Got a list of possible display manager names he should be looking for?
And you can't tell from where it launches?
Find (using the find command or locate if that's installed) every file less than 50K on the root/ boot systems ( And if you can't figure that, just tell it not to traverse network links, hopefully you won't waste time going through too many files ) and grep it for that text. You will find the launch script somewhere. The launch configuration file. You will find at least one and possibly multiples.
At that point, you can typically insert the strace command before the actual command.
Edited by crazy
June 15, 2022, 03:40:51 PM EDT
Edited by crazy
June 15, 2022, 04:02:38 PM EDT
|
