Do bug corrections spread automatically to all Linux distros and updates? [closed]

up vote
0
down vote

favorite

I'm using Debian 9. When turning off my computer, many times (more than 50%, I think) I get the following message:

A stop job is running for Session 3 of user rodrigo (Xs / 1min 30s)

X increments till the time is through, then the computer finally turns off. Sometimes there are two different "stop jobs" whose messages and timers alternate on this same line. Googling it ("a stop job is running for" debian 9), I've found many similar bugs in different distros (47 results only in bugs.debian.org), some more than 4 years old.

My question is: aren't most of these errors coming from the same package? Hasn't it been fixed yet? (Most solutions are only workarounds.) Isn't the source code developed by a single person or team, and compiled separately to the different Linux distros? If the error has been fixed in the source code (I think it should by now), then why this error still appears four years later? Isn't that too long? Or maybe it's been fixed in other distros, but not yet on Debian?

asked Dec 10 at 4:26

Rodrigo

2201318

closed as primarily opinion-based by Thomas Dickey, nwildner, JigglyNaga, Christopher, GAD3R Dec 10 at 18:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

I think you're a witch because you can predict things just by thinking.
– 神秘德里克
Dec 10 at 5:17

4

This is not an error message and generated by the famous systemd.
– Ipor Sircer
Dec 10 at 5:21

@IporSircer To me it seems an error, because if Firefox (for instance) is open when I turn the machine off, Firefox is automatically closed. Which program is this that systemd apparently is unable to close? And why should it be there? I'm proud of Debian being much faster than Windows, both to turn on and to turn off. So if I have to wait 90s to turn it off, at unpredictable moments, then it seems an error to me. And since this is listed as a "bug" so many times, I ask if you mean the "infamous" systemd?
– Rodrigo
Dec 10 at 19:12

1

This is a message printed by systemd when there is an application/service/process that does not terminate itself after being receiving a polite kill signal. aren't most of these errors coming from the same package? Hasn't it been fixed yet? Probably not, there are many reasons services may get into an unkillable state. New system services come and go all the time, so even if you fix one chances are a different service may introduce new features that produces the same message, and in many cases, they only get into this state because of your specific system's configuration.
– Lie Ryan
Dec 15 at 10:09

add a comment |

up vote
0
down vote

favorite

I'm using Debian 9. When turning off my computer, many times (more than 50%, I think) I get the following message:

A stop job is running for Session 3 of user rodrigo (Xs / 1min 30s)

asked Dec 10 at 4:26

Rodrigo

2201318

closed as primarily opinion-based by Thomas Dickey, nwildner, JigglyNaga, Christopher, GAD3R Dec 10 at 18:10

I think you're a witch because you can predict things just by thinking.
– 神秘德里克
Dec 10 at 5:17

4

This is not an error message and generated by the famous systemd.
– Ipor Sircer
Dec 10 at 5:21

@IporSircer To me it seems an error, because if Firefox (for instance) is open when I turn the machine off, Firefox is automatically closed. Which program is this that systemd apparently is unable to close? And why should it be there? I'm proud of Debian being much faster than Windows, both to turn on and to turn off. So if I have to wait 90s to turn it off, at unpredictable moments, then it seems an error to me. And since this is listed as a "bug" so many times, I ask if you mean the "infamous" systemd?
– Rodrigo
Dec 10 at 19:12

1

This is a message printed by systemd when there is an application/service/process that does not terminate itself after being receiving a polite kill signal. aren't most of these errors coming from the same package? Hasn't it been fixed yet? Probably not, there are many reasons services may get into an unkillable state. New system services come and go all the time, so even if you fix one chances are a different service may introduce new features that produces the same message, and in many cases, they only get into this state because of your specific system's configuration.
– Lie Ryan
Dec 15 at 10:09

add a comment |

up vote
0
down vote

favorite

I'm using Debian 9. When turning off my computer, many times (more than 50%, I think) I get the following message:

A stop job is running for Session 3 of user rodrigo (Xs / 1min 30s)

asked Dec 10 at 4:26

Rodrigo

2201318

I'm using Debian 9. When turning off my computer, many times (more than 50%, I think) I get the following message:

A stop job is running for Session 3 of user rodrigo (Xs / 1min 30s)

upgrade distributions bugs

asked Dec 10 at 4:26

Rodrigo

2201318

asked Dec 10 at 4:26

Rodrigo

2201318

asked Dec 10 at 4:26

Rodrigo

2201318

asked Dec 10 at 4:26

Rodrigo

2201318

asked Dec 10 at 4:26

Rodrigo

2201318

closed as primarily opinion-based by Thomas Dickey, nwildner, JigglyNaga, Christopher, GAD3R Dec 10 at 18:10

I think you're a witch because you can predict things just by thinking.
– 神秘德里克
Dec 10 at 5:17

4

This is not an error message and generated by the famous systemd.
– Ipor Sircer
Dec 10 at 5:21

@IporSircer To me it seems an error, because if Firefox (for instance) is open when I turn the machine off, Firefox is automatically closed. Which program is this that systemd apparently is unable to close? And why should it be there? I'm proud of Debian being much faster than Windows, both to turn on and to turn off. So if I have to wait 90s to turn it off, at unpredictable moments, then it seems an error to me. And since this is listed as a "bug" so many times, I ask if you mean the "infamous" systemd?
– Rodrigo
Dec 10 at 19:12

1

This is a message printed by systemd when there is an application/service/process that does not terminate itself after being receiving a polite kill signal. aren't most of these errors coming from the same package? Hasn't it been fixed yet? Probably not, there are many reasons services may get into an unkillable state. New system services come and go all the time, so even if you fix one chances are a different service may introduce new features that produces the same message, and in many cases, they only get into this state because of your specific system's configuration.
– Lie Ryan
Dec 15 at 10:09

add a comment |

I think you're a witch because you can predict things just by thinking.
– 神秘德里克
Dec 10 at 5:17

4

This is not an error message and generated by the famous systemd.
– Ipor Sircer
Dec 10 at 5:21

@IporSircer To me it seems an error, because if Firefox (for instance) is open when I turn the machine off, Firefox is automatically closed. Which program is this that systemd apparently is unable to close? And why should it be there? I'm proud of Debian being much faster than Windows, both to turn on and to turn off. So if I have to wait 90s to turn it off, at unpredictable moments, then it seems an error to me. And since this is listed as a "bug" so many times, I ask if you mean the "infamous" systemd?
– Rodrigo
Dec 10 at 19:12

1

This is a message printed by systemd when there is an application/service/process that does not terminate itself after being receiving a polite kill signal. aren't most of these errors coming from the same package? Hasn't it been fixed yet? Probably not, there are many reasons services may get into an unkillable state. New system services come and go all the time, so even if you fix one chances are a different service may introduce new features that produces the same message, and in many cases, they only get into this state because of your specific system's configuration.
– Lie Ryan
Dec 15 at 10:09

I think you're a witch because you can predict things just by thinking.
– 神秘德里克
Dec 10 at 5:17

This is not an error message and generated by the famous systemd.
– Ipor Sircer
Dec 10 at 5:21

@IporSircer To me it seems an error, because if Firefox (for instance) is open when I turn the machine off, Firefox is automatically closed. Which program is this that systemd apparently is unable to close? And why should it be there? I'm proud of Debian being much faster than Windows, both to turn on and to turn off. So if I have to wait 90s to turn it off, at unpredictable moments, then it seems an error to me. And since this is listed as a "bug" so many times, I ask if you mean the "infamous" systemd?
– Rodrigo
Dec 10 at 19:12

This is a message printed by systemd when there is an application/service/process that does not terminate itself after being receiving a polite kill signal. aren't most of these errors coming from the same package? Hasn't it been fixed yet? Probably not, there are many reasons services may get into an unkillable state. New system services come and go all the time, so even if you fix one chances are a different service may introduce new features that produces the same message, and in many cases, they only get into this state because of your specific system's configuration.
– Lie Ryan
Dec 15 at 10:09

add a comment |

1 Answer
1

active

oldest

votes

up vote
1
down vote

There's no "automatic" spread of of patches. Neither for the Linux kernel, nor of any other OS component like libraries, programs etc.

This happens for a number of reasons, that mainly boil down to these ones:

Almost all distributions apply their very own patches to the "official sources" before creating binary packages. This leads to a non-trivial amount of work to apply possible official, unofficial and out-of-branch security and bug-fix patches. And some of those patches aren't just fixes: they can be needed in order for a package to comply to the distribution policies (like adding a mandatory --help or --long-help and the likes).

The timing those "official patches" get to a distribution can vary widely, depending upon a number of reasons like human resources, patch review policies and the likes. Sometimes there are distributions that won't apply some patches.

Distributions like Ubuntu have "support" policies that can slow down and even block any update to a distribution once it gets "end of life". On the other side, rolling distributions tend to keep up with the "official" patches and new releases.

For general updates about patches, bug-fixes and security pathces, I'd like to suggest you websites like Linux Weekly News and Phoronix.

All that said, the error you are reporting clearly says that there's some process of yours still running while shutting down the system.
I'd suggest you to run some tests right before doing the shutdown, just to know which process is hanging.

In my opinion, ps is your friend and you could run it straigth from a vty (virtual console tty).

Press Ctrl+Alt+F1 (or F2 or F3) to get a vty. It's the non-GUI login.

Run PS_FORMAT='ruser,pid,ppid,s,%cpu,rss,cmd' ps x (my personal favorite). It will show you the all the process running as "you" along with some details. Replace ps x with ps ax to see all processes.

Take note of those processes: PID is the process ID, PPID is the parent process ID, that of the process who spawned that process, CMD is the command being run.

Try closing/killing them before doing the shutdown.

edited Dec 15 at 9:56

answered Dec 10 at 10:19

EnzoR

242129

Thank you. From one comment, let's suppose the problem is in systemd. About your point 1 above, wouldn't it be wiser to patch the original code once and for all, instead of each distribution applying a different patch? That sounds like do the same work again... About number 3, I'm using Debian 9, so no "end of life" here. About ps isn't it the same as see the process listing in System Monitor? How can I know which process is blocking my turn off? And should I be closing/killing this process by myself every time? That's not a solution!
– Rodrigo
Dec 10 at 19:22

1

I added some more explanation about patching. For debian, you'd better check the documentation like en.wikipedia.org/wiki/Debian_version_history#Release_table . Again, you have to investigate with tools like ps and lsof for example. Dabian Handbook can be of help (debian-handbook.info).
– EnzoR
Dec 15 at 9:58

add a comment |

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

up vote
1
down vote

There's no "automatic" spread of of patches. Neither for the Linux kernel, nor of any other OS component like libraries, programs etc.

This happens for a number of reasons, that mainly boil down to these ones:

Almost all distributions apply their very own patches to the "official sources" before creating binary packages. This leads to a non-trivial amount of work to apply possible official, unofficial and out-of-branch security and bug-fix patches. And some of those patches aren't just fixes: they can be needed in order for a package to comply to the distribution policies (like adding a mandatory --help or --long-help and the likes).

The timing those "official patches" get to a distribution can vary widely, depending upon a number of reasons like human resources, patch review policies and the likes. Sometimes there are distributions that won't apply some patches.

Distributions like Ubuntu have "support" policies that can slow down and even block any update to a distribution once it gets "end of life". On the other side, rolling distributions tend to keep up with the "official" patches and new releases.

For general updates about patches, bug-fixes and security pathces, I'd like to suggest you websites like Linux Weekly News and Phoronix.

In my opinion, ps is your friend and you could run it straigth from a vty (virtual console tty).

Press Ctrl+Alt+F1 (or F2 or F3) to get a vty. It's the non-GUI login.

Run PS_FORMAT='ruser,pid,ppid,s,%cpu,rss,cmd' ps x (my personal favorite). It will show you the all the process running as "you" along with some details. Replace ps x with ps ax to see all processes.

Take note of those processes: PID is the process ID, PPID is the parent process ID, that of the process who spawned that process, CMD is the command being run.

Try closing/killing them before doing the shutdown.

edited Dec 15 at 9:56

answered Dec 10 at 10:19

EnzoR

242129

Thank you. From one comment, let's suppose the problem is in systemd. About your point 1 above, wouldn't it be wiser to patch the original code once and for all, instead of each distribution applying a different patch? That sounds like do the same work again... About number 3, I'm using Debian 9, so no "end of life" here. About ps isn't it the same as see the process listing in System Monitor? How can I know which process is blocking my turn off? And should I be closing/killing this process by myself every time? That's not a solution!
– Rodrigo
Dec 10 at 19:22

1

I added some more explanation about patching. For debian, you'd better check the documentation like en.wikipedia.org/wiki/Debian_version_history#Release_table . Again, you have to investigate with tools like ps and lsof for example. Dabian Handbook can be of help (debian-handbook.info).
– EnzoR
Dec 15 at 9:58

add a comment |

up vote
1
down vote

There's no "automatic" spread of of patches. Neither for the Linux kernel, nor of any other OS component like libraries, programs etc.

This happens for a number of reasons, that mainly boil down to these ones:

Almost all distributions apply their very own patches to the "official sources" before creating binary packages. This leads to a non-trivial amount of work to apply possible official, unofficial and out-of-branch security and bug-fix patches. And some of those patches aren't just fixes: they can be needed in order for a package to comply to the distribution policies (like adding a mandatory --help or --long-help and the likes).

The timing those "official patches" get to a distribution can vary widely, depending upon a number of reasons like human resources, patch review policies and the likes. Sometimes there are distributions that won't apply some patches.

Distributions like Ubuntu have "support" policies that can slow down and even block any update to a distribution once it gets "end of life". On the other side, rolling distributions tend to keep up with the "official" patches and new releases.

For general updates about patches, bug-fixes and security pathces, I'd like to suggest you websites like Linux Weekly News and Phoronix.

In my opinion, ps is your friend and you could run it straigth from a vty (virtual console tty).

Press Ctrl+Alt+F1 (or F2 or F3) to get a vty. It's the non-GUI login.

Run PS_FORMAT='ruser,pid,ppid,s,%cpu,rss,cmd' ps x (my personal favorite). It will show you the all the process running as "you" along with some details. Replace ps x with ps ax to see all processes.

Take note of those processes: PID is the process ID, PPID is the parent process ID, that of the process who spawned that process, CMD is the command being run.

Try closing/killing them before doing the shutdown.

edited Dec 15 at 9:56

answered Dec 10 at 10:19

EnzoR

242129

Thank you. From one comment, let's suppose the problem is in systemd. About your point 1 above, wouldn't it be wiser to patch the original code once and for all, instead of each distribution applying a different patch? That sounds like do the same work again... About number 3, I'm using Debian 9, so no "end of life" here. About ps isn't it the same as see the process listing in System Monitor? How can I know which process is blocking my turn off? And should I be closing/killing this process by myself every time? That's not a solution!
– Rodrigo
Dec 10 at 19:22

1

I added some more explanation about patching. For debian, you'd better check the documentation like en.wikipedia.org/wiki/Debian_version_history#Release_table . Again, you have to investigate with tools like ps and lsof for example. Dabian Handbook can be of help (debian-handbook.info).
– EnzoR
Dec 15 at 9:58

add a comment |

up vote
1
down vote

There's no "automatic" spread of of patches. Neither for the Linux kernel, nor of any other OS component like libraries, programs etc.

This happens for a number of reasons, that mainly boil down to these ones:

Almost all distributions apply their very own patches to the "official sources" before creating binary packages. This leads to a non-trivial amount of work to apply possible official, unofficial and out-of-branch security and bug-fix patches. And some of those patches aren't just fixes: they can be needed in order for a package to comply to the distribution policies (like adding a mandatory --help or --long-help and the likes).

The timing those "official patches" get to a distribution can vary widely, depending upon a number of reasons like human resources, patch review policies and the likes. Sometimes there are distributions that won't apply some patches.

Distributions like Ubuntu have "support" policies that can slow down and even block any update to a distribution once it gets "end of life". On the other side, rolling distributions tend to keep up with the "official" patches and new releases.

For general updates about patches, bug-fixes and security pathces, I'd like to suggest you websites like Linux Weekly News and Phoronix.

In my opinion, ps is your friend and you could run it straigth from a vty (virtual console tty).

Press Ctrl+Alt+F1 (or F2 or F3) to get a vty. It's the non-GUI login.

Run PS_FORMAT='ruser,pid,ppid,s,%cpu,rss,cmd' ps x (my personal favorite). It will show you the all the process running as "you" along with some details. Replace ps x with ps ax to see all processes.

Take note of those processes: PID is the process ID, PPID is the parent process ID, that of the process who spawned that process, CMD is the command being run.

Try closing/killing them before doing the shutdown.

edited Dec 15 at 9:56

answered Dec 10 at 10:19

EnzoR

242129

There's no "automatic" spread of of patches. Neither for the Linux kernel, nor of any other OS component like libraries, programs etc.

This happens for a number of reasons, that mainly boil down to these ones:

Almost all distributions apply their very own patches to the "official sources" before creating binary packages. This leads to a non-trivial amount of work to apply possible official, unofficial and out-of-branch security and bug-fix patches. And some of those patches aren't just fixes: they can be needed in order for a package to comply to the distribution policies (like adding a mandatory --help or --long-help and the likes).

The timing those "official patches" get to a distribution can vary widely, depending upon a number of reasons like human resources, patch review policies and the likes. Sometimes there are distributions that won't apply some patches.

Distributions like Ubuntu have "support" policies that can slow down and even block any update to a distribution once it gets "end of life". On the other side, rolling distributions tend to keep up with the "official" patches and new releases.

For general updates about patches, bug-fixes and security pathces, I'd like to suggest you websites like Linux Weekly News and Phoronix.

In my opinion, ps is your friend and you could run it straigth from a vty (virtual console tty).

Press Ctrl+Alt+F1 (or F2 or F3) to get a vty. It's the non-GUI login.

Run PS_FORMAT='ruser,pid,ppid,s,%cpu,rss,cmd' ps x (my personal favorite). It will show you the all the process running as "you" along with some details. Replace ps x with ps ax to see all processes.

Take note of those processes: PID is the process ID, PPID is the parent process ID, that of the process who spawned that process, CMD is the command being run.

Try closing/killing them before doing the shutdown.

edited Dec 15 at 9:56

answered Dec 10 at 10:19

EnzoR

242129

edited Dec 15 at 9:56

answered Dec 10 at 10:19

EnzoR

242129

answered Dec 10 at 10:19

EnzoR

242129

answered Dec 10 at 10:19

EnzoR

242129

Thank you. From one comment, let's suppose the problem is in systemd. About your point 1 above, wouldn't it be wiser to patch the original code once and for all, instead of each distribution applying a different patch? That sounds like do the same work again... About number 3, I'm using Debian 9, so no "end of life" here. About ps isn't it the same as see the process listing in System Monitor? How can I know which process is blocking my turn off? And should I be closing/killing this process by myself every time? That's not a solution!
– Rodrigo
Dec 10 at 19:22

1

I added some more explanation about patching. For debian, you'd better check the documentation like en.wikipedia.org/wiki/Debian_version_history#Release_table . Again, you have to investigate with tools like ps and lsof for example. Dabian Handbook can be of help (debian-handbook.info).
– EnzoR
Dec 15 at 9:58

add a comment |

Thank you. From one comment, let's suppose the problem is in systemd. About your point 1 above, wouldn't it be wiser to patch the original code once and for all, instead of each distribution applying a different patch? That sounds like do the same work again... About number 3, I'm using Debian 9, so no "end of life" here. About ps isn't it the same as see the process listing in System Monitor? How can I know which process is blocking my turn off? And should I be closing/killing this process by myself every time? That's not a solution!
– Rodrigo
Dec 10 at 19:22

1

I added some more explanation about patching. For debian, you'd better check the documentation like en.wikipedia.org/wiki/Debian_version_history#Release_table . Again, you have to investigate with tools like ps and lsof for example. Dabian Handbook can be of help (debian-handbook.info).
– EnzoR
Dec 15 at 9:58

Thank you. From one comment, let's suppose the problem is in systemd. About your point 1 above, wouldn't it be wiser to patch the original code once and for all, instead of each distribution applying a different patch? That sounds like do the same work again... About number 3, I'm using Debian 9, so no "end of life" here. About ps isn't it the same as see the process listing in System Monitor? How can I know which process is blocking my turn off? And should I be closing/killing this process by myself every time? That's not a solution!
– Rodrigo
Dec 10 at 19:22

I added some more explanation about patching. For debian, you'd better check the documentation like en.wikipedia.org/wiki/Debian_version_history#Release_table . Again, you have to investigate with tools like ps and lsof for example. Dabian Handbook can be of help (debian-handbook.info).
– EnzoR
Dec 15 at 9:58

add a comment |

搜尋此網誌

mjhjmtu