[Touch-packages] [Bug 2037399] Re: Processes keep running after "systemctl stop"
This seems to be a related problem: Sep 29 07:00:30 hyades systemd[1]: apt-daily-upgrade.service: Unit process 51088 (exim4) remains running after unit stopped. I would think that apt-daily-upgrade relies on exim4 getting actually restarted after an update. If the process remains running, does that not potentially cause trouble? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037399 Title: Processes keep running after "systemctl stop" Status in systemd package in Ubuntu: New Bug description: I have a number of Ubuntu 22.04 installations on various computers. In the last month, I have seen more and more log messages like the following from different systems: ``` systemd[1]: apache2.service: Unit process 70257 (apache2) remains running after unit stopped. systemd[1]: exim4.service: Unit process 61890 (exim4) remains running after unit stopped. ``` I started considering this a problem when subsequently, some php processes continued running after `systemctl stop apache2.service`. This can be a problem when rogue processes interfere with my file- based backup. I had at least one case where a rogue `php` process started misbehaving after both `apache2` and `mysql` where stopped. The `php` processes continued running, possibly inside a rogue `apache2` process, but failed to continue its normal operation due to the absence of `mysql`. Motivation: I have a nightly backup script that stops common services like `exim4`, `apache2` and `mysql`, then performs file-based backup, and subsequently starts services again. I was relying on the fact that processes would end after `systemctl stop`, and do not modify the file system anymore. But this seems not always to be the case? I do not necessarily think that this is a duplicate of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2013543. The way I understand the other bug is that systemd forgets about running processes. Here in my case, systemd seems well aware that not all processes ended, at least this is what the log message indicates. But systemd does not force them to quit. Expected behavior: After `systemctl stop`, I would need all processes to end. This would be required so that I can be sure that it is safe to perform file based backup, without modifications on the file system. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2037399/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2037399] Re: Processes keep running after "systemctl stop"
I'm running systemd:amd64 249.11-0ubuntu3.10 from jammy-updates on Ubuntu 22.04.3 LTS. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037399 Title: Processes keep running after "systemctl stop" Status in systemd package in Ubuntu: New Bug description: I have a number of Ubuntu 22.04 installations on various computers. In the last month, I have seen more and more log messages like the following from different systems: ``` systemd[1]: apache2.service: Unit process 70257 (apache2) remains running after unit stopped. systemd[1]: exim4.service: Unit process 61890 (exim4) remains running after unit stopped. ``` I started considering this a problem when subsequently, some php processes continued running after `systemctl stop apache2.service`. This can be a problem when rogue processes interfere with my file- based backup. I had at least one case where a rogue `php` process started misbehaving after both `apache2` and `mysql` where stopped. The `php` processes continued running, possibly inside a rogue `apache2` process, but failed to continue its normal operation due to the absence of `mysql`. Motivation: I have a nightly backup script that stops common services like `exim4`, `apache2` and `mysql`, then performs file-based backup, and subsequently starts services again. I was relying on the fact that processes would end after `systemctl stop`, and do not modify the file system anymore. But this seems not always to be the case? I do not necessarily think that this is a duplicate of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2013543. The way I understand the other bug is that systemd forgets about running processes. Here in my case, systemd seems well aware that not all processes ended, at least this is what the log message indicates. But systemd does not force them to quit. Expected behavior: After `systemctl stop`, I would need all processes to end. This would be required so that I can be sure that it is safe to perform file based backup, without modifications on the file system. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2037399/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2037399] [NEW] Processes keep running after "systemctl stop"
Public bug reported: I have a number of Ubuntu 22.04 installations on various computers. In the last month, I have seen more and more log messages like the following from different systems: ``` systemd[1]: apache2.service: Unit process 70257 (apache2) remains running after unit stopped. systemd[1]: exim4.service: Unit process 61890 (exim4) remains running after unit stopped. ``` I started considering this a problem when subsequently, some php processes continued running after `systemctl stop apache2.service`. This can be a problem when rogue processes interfere with my file-based backup. I had at least one case where a rogue `php` process started misbehaving after both `apache2` and `mysql` where stopped. The `php` processes continued running, possibly inside a rogue `apache2` process, but failed to continue its normal operation due to the absence of `mysql`. Motivation: I have a nightly backup script that stops common services like `exim4`, `apache2` and `mysql`, then performs file-based backup, and subsequently starts services again. I was relying on the fact that processes would end after `systemctl stop`, and do not modify the file system anymore. But this seems not always to be the case? I do not necessarily think that this is a duplicate of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2013543. The way I understand the other bug is that systemd forgets about running processes. Here in my case, systemd seems well aware that not all processes ended, at least this is what the log message indicates. But systemd does not force them to quit. Expected behavior: After `systemctl stop`, I would need all processes to end. This would be required so that I can be sure that it is safe to perform file based backup, without modifications on the file system. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037399 Title: Processes keep running after "systemctl stop" Status in systemd package in Ubuntu: New Bug description: I have a number of Ubuntu 22.04 installations on various computers. In the last month, I have seen more and more log messages like the following from different systems: ``` systemd[1]: apache2.service: Unit process 70257 (apache2) remains running after unit stopped. systemd[1]: exim4.service: Unit process 61890 (exim4) remains running after unit stopped. ``` I started considering this a problem when subsequently, some php processes continued running after `systemctl stop apache2.service`. This can be a problem when rogue processes interfere with my file- based backup. I had at least one case where a rogue `php` process started misbehaving after both `apache2` and `mysql` where stopped. The `php` processes continued running, possibly inside a rogue `apache2` process, but failed to continue its normal operation due to the absence of `mysql`. Motivation: I have a nightly backup script that stops common services like `exim4`, `apache2` and `mysql`, then performs file-based backup, and subsequently starts services again. I was relying on the fact that processes would end after `systemctl stop`, and do not modify the file system anymore. But this seems not always to be the case? I do not necessarily think that this is a duplicate of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2013543. The way I understand the other bug is that systemd forgets about running processes. Here in my case, systemd seems well aware that not all processes ended, at least this is what the log message indicates. But systemd does not force them to quit. Expected behavior: After `systemctl stop`, I would need all processes to end. This would be required so that I can be sure that it is safe to perform file based backup, without modifications on the file system. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2037399/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1508826] Re: [20ANCTO1WW, Realtek ALC3232, Black Headphone Out, Left] No sound at all when headset plugged in
None of the solutions above work for me. I don't have a dock, just the headset jack on T440p. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1508826 Title: [20ANCTO1WW, Realtek ALC3232, Black Headphone Out, Left] No sound at all when headset plugged in Status in alsa-driver package in Ubuntu: Confirmed Bug description: Sounds works fine through the internal speakers, but once I plug a headset or headphones (I tried two things, in case one was broken) in to the audio out, I get nothing. Looking in alsamixer, plugging the headset in mutes the 'Speaker' output and unmutes the 'Headphone' output, and restores the Master volume to its previous headset-in value. Unplugging the headset does the opposite (mutes 'Headphone'; unmutes 'Speaker'), as I would expect. This was working on vivid, so a definite regression, I think. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: daniel 5155 F pulseaudio /dev/snd/controlC0: daniel 5155 F pulseaudio Date: Thu Oct 22 09:37:39 2015 EcryptfsInUse: Yes InstallationDate: Installed on 2014-09-04 (412 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_DevicesInUse: Error: command ['pkexec', 'fuser', '-v', '/dev/snd/by-path', '/dev/snd/hwC1D0', '/dev/snd/pcmC1D0c', '/dev/snd/pcmC1D0p', '/dev/snd/controlC1', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D8p', '/dev/snd/pcmC0D7p', '/dev/snd/pcmC0D3p', '/dev/snd/controlC0', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie Error executing command as another user: Not authorized This incident has been reported. Symptom_Jack: Black Headphone Out, Left Symptom_Type: No sound at all Title: [20ANCTO1WW, Realtek ALC3232, Black Headphone Out, Left] No sound at all UpgradeStatus: Upgraded to wily on 2015-10-21 (0 days ago) dmi.bios.date: 05/21/2014 dmi.bios.vendor: LENOVO dmi.bios.version: GLET70WW (2.24 ) dmi.board.asset.tag: Not Available dmi.board.name: 20ANCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0E50512 STD dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrGLET70WW(2.24):bd05/21/2014:svnLENOVO:pn20ANCTO1WW:pvrThinkPadT440p:rvnLENOVO:rn20ANCTO1WW:rvrSDK0E50512STD:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 20ANCTO1WW dmi.product.version: ThinkPad T440p dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1508826/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
