Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #161396 > unrolled thread
| Started by | Jape Person <japers@comcast.net> |
|---|---|
| First post | 2015-12-01 03:20 +0100 |
| Last post | 2015-12-03 13:10 +0100 |
| Articles | 20 on this page of 37 — 14 participants |
Back to article view | Back to linux.debian.user
A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-01 03:20 +0100
Re: A stop job is running for... Sven Arvidsson <sa@whiz.se> - 2015-12-01 15:50 +0100
Re: A stop job is running for... "James P. Wallen" <jpwallen@comcast.net> - 2015-12-02 04:40 +0100
Re: A stop job is running for... Martin Read <zen75502@zen.co.uk> - 2015-12-02 12:10 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 16:20 +0100
Re: A stop job is running for... "James P. Wallen" <jpwallen@comcast.net> - 2015-12-02 16:20 +0100
Re: A stop job is running for... Himanshu Shekhar <irm2015006@iiita.ac.in> - 2015-12-03 11:30 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-03 18:20 +0100
Re: A stop job is running for... Michael Biebl <biebl@debian.org> - 2015-12-03 19:10 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-03 21:30 +0100
Re: A stop job is running for... Michael Biebl <biebl@debian.org> - 2015-12-03 22:10 +0100
Systemd debugging (was ... Re: A stop job is running for...) Chris Bannister <cbannister@slingshot.co.nz> - 2015-12-04 10:20 +0100
Re: A stop job is running for... Rick Thomas <rbthomas@pobox.com> - 2015-12-03 19:30 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-03 22:20 +0100
Re: A stop job is running for... David Wright <deblis@lionunicorn.co.uk> - 2015-12-02 17:00 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 18:10 +0100
Re: A stop job is running for... Michael Biebl <biebl@debian.org> - 2015-12-02 18:20 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 19:00 +0100
Re: A stop job is running for... Michael Biebl <biebl@debian.org> - 2015-12-02 20:10 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 20:30 +0100
Re: A stop job is running for... David Wright <deblis@lionunicorn.co.uk> - 2015-12-06 03:30 +0100
Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-02 19:30 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 20:10 +0100
Re: A stop job is running for... Don Armstrong <don@debian.org> - 2015-12-03 00:00 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-03 00:40 +0100
Re: A stop job is running for... David Wright <deblis@lionunicorn.co.uk> - 2015-12-03 20:20 +0100
Re: A stop job is running for... Don Armstrong <don@debian.org> - 2015-12-04 19:50 +0100
Re: A stop job is running for... Himanshu Shekhar <irm2015006@iiita.ac.in> - 2015-12-05 07:30 +0100
Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-05 17:10 +0100
Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-03 02:20 +0100
Re: A stop job is running for... Chris Bannister <cbannister@slingshot.co.nz> - 2015-12-03 03:50 +0100
Re: A stop job is running for... "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu> - 2015-12-03 04:10 +0100
Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-03 04:30 +0100
Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-03 04:30 +0100
Re: A stop job is running for... Nicolas George <george@nsup.org> - 2015-12-03 08:50 +0100
Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-03 12:00 +0100
Re: A stop job is running for... <tomas@tuxteam.de> - 2015-12-03 13:10 +0100
Page 1 of 2 [1] 2 Next page →
| From | Jape Person <japers@comcast.net> |
|---|---|
| Date | 2015-12-01 03:20 +0100 |
| Subject | A stop job is running for... |
| Message-ID | <qAIHT-3rX-1@gated-at.bofh.it> |
Make remote CUPS printers available locally Network Time Synchronization For several weeks I've been seeing this stop job notification for these two items frequently when rebooting or shutting down two of my four testing systems. The first notification counts all the way up to 1 min 30 sec before the shutdown scroll restarts. The second notification only counts for a few seconds before terminating. I'm a patient guy, but adding almost two minutes to almost every restart or shutdown procedure gets a bit tedious after a while. This is a small home network with 4 systems running Debian Stretch and two printers. One printer is attached via USB to one of the Stretch systems showing the error. It is shared on the network. The other printer is a network MFP attached via CAT5e to the router. The two Stretch systems which show this behavior are both used directly through the desktop environment. The other two PCs are only accessed ordinarily via SSH, and I have not seen them display the notification. (They sit near my workstation, and I can watch their screens when rebooting or shutting them down.) The systems use Xfce DE and LightDM. The USB printer was set up using CUPS. The network MFP was installed using the hp-setup utility from hplip. Both printers are installed on all four systems. The only possibly related hit when searching -- interestingly enough -- concerned cups-bsd in the MacOS and the HP LaserJet 1300 printer from a few years ago. An HP LaserJet 1300 happens to be the USB-attached printer on this network. The only advice offered to fix the problem was to restart the computer and the printer. I didn't think that would fix the issue, and it didn't. I found nothing pertinent in the Debian bug tracker on the cups-bsd package. Suggestions, anyone? I'm grateful for your time and any ideas you might provide.
[toc] | [next] | [standalone]
| From | Sven Arvidsson <sa@whiz.se> |
|---|---|
| Date | 2015-12-01 15:50 +0100 |
| Message-ID | <qAUpI-2rO-15@gated-at.bofh.it> |
| In reply to | #161396 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, 2015-11-30 at 21:04 -0500, Jape Person wrote: > Make remote CUPS printers available locally > Network Time Synchronization > > For several weeks I've been seeing this stop job notification for > these > two items frequently when rebooting or shutting down two of my four > testing systems. > > The first notification counts all the way up to 1 min 30 sec before > the > shutdown scroll restarts. The second notification only counts for a > few > seconds before terminating. > > I'm a patient guy, but adding almost two minutes to almost every > restart > or shutdown procedure gets a bit tedious after a while. Yes, I have noticed this too, but with different services. So it's probably not specific to CUPS or NTP. Unfortunately it seems to always happen when I need to shutdown quickly (thunderstorms). Would be great if it was possible to configure the countdown to simply kill the service after a few seconds and proceed with shutdown/reboot. -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 6FAB5CD5
[toc] | [prev] | [next] | [standalone]
| From | "James P. Wallen" <jpwallen@comcast.net> |
|---|---|
| Date | 2015-12-02 04:40 +0100 |
| Message-ID | <qB6qS-1LU-1@gated-at.bofh.it> |
| In reply to | #161418 |
On 12/01/2015 09:47 AM, Sven Arvidsson wrote: > On Mon, 2015-11-30 at 21:04 -0500, Jape Person wrote: >> Make remote CUPS printers available locally >> Network Time Synchronization >> >> For several weeks I've been seeing this stop job notification for >> these >> two items frequently when rebooting or shutting down two of my four >> testing systems. >> >> The first notification counts all the way up to 1 min 30 sec before >> the >> shutdown scroll restarts. The second notification only counts for a >> few >> seconds before terminating. >> >> I'm a patient guy, but adding almost two minutes to almost every >> restart >> or shutdown procedure gets a bit tedious after a while. > > Yes, I have noticed this too, but with different services. So it's > probably not specific to CUPS or NTP. > > Unfortunately it seems to always happen when I need to shutdown quickly > (thunderstorms). Would be great if it was possible to configure the > countdown to simply kill the service after a few seconds and proceed > with shutdown/reboot. > Thanks for your response, Sven. It's nice to know that someone else has seen this type of problem. I was thinking that this could be self-inflicted. Perhaps that's a little less likely now. So, is this behavior controlled by systemd? I'm not trying to start a fracas. I'm really interested. What I'm asking is, do I need to start poring over systemd documentation to see if there might be a way to control this behavior?
[toc] | [prev] | [next] | [standalone]
| From | Martin Read <zen75502@zen.co.uk> |
|---|---|
| Date | 2015-12-02 12:10 +0100 |
| Message-ID | <qBdsn-6oc-31@gated-at.bofh.it> |
| In reply to | #161446 |
On 02/12/15 03:07, James P. Wallen wrote: > Thanks for your response, Sven. It's nice to know that someone else has > seen this type of problem. I was thinking that this could be > self-inflicted. Perhaps that's a little less likely now. > > So, is this behavior controlled by systemd? > > I'm not trying to start a fracas. I'm really interested. What I'm asking > is, do I need to start poring over systemd documentation to see if there > might be a way to control this behavior? If a stop job is taking two minutes, that suggests that the service has one or more ExecStop lines defined in its service unit and that one of those commands is taking an unduly long time to complete for some reason. The default and per-service timeout values for stopping a service (after which systemd gives up and sends fatal signals to all of the service's processes) are configurable; see the systemd-system.conf(5) and systemd.service(5) man pages for details.
[toc] | [prev] | [next] | [standalone]
| From | Jape Person <japers@comcast.net> |
|---|---|
| Date | 2015-12-02 16:20 +0100 |
| Message-ID | <qBhmi-sK-15@gated-at.bofh.it> |
| In reply to | #161453 |
On 12/02/2015 06:06 AM, Martin Read wrote: > The default and per-service timeout values for stopping a service (after > which systemd gives up and sends fatal signals to all of the service's > processes) are configurable; see the systemd-system.conf(5) and > systemd.service(5) man pages for details. > > This could be useful. Time to wade into the man pages. I'm grateful.
[toc] | [prev] | [next] | [standalone]
| From | "James P. Wallen" <jpwallen@comcast.net> |
|---|---|
| Date | 2015-12-02 16:20 +0100 |
| Message-ID | <qBhmi-sK-23@gated-at.bofh.it> |
| In reply to | #161453 |
On 12/02/2015 06:06 AM, Martin Read wrote: > On 02/12/15 03:07, James P. Wallen wrote: >> Thanks for your response, Sven. It's nice to know that someone else has >> seen this type of problem. I was thinking that this could be >> self-inflicted. Perhaps that's a little less likely now. >> >> So, is this behavior controlled by systemd? >> >> I'm not trying to start a fracas. I'm really interested. What I'm asking >> is, do I need to start poring over systemd documentation to see if there >> might be a way to control this behavior? > > If a stop job is taking two minutes, that suggests that the service has > one or more ExecStop lines defined in its service unit and that one of > those commands is taking an unduly long time to complete for some reason. > > The default and per-service timeout values for stopping a service (after > which systemd gives up and sends fatal signals to all of the service's > processes) are configurable; see the systemd-system.conf(5) and > systemd.service(5) man pages for details. > > I'm going to look into this right away and do some testing to see if I can fix the problems on my system. Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Himanshu Shekhar <irm2015006@iiita.ac.in> |
|---|---|
| Date | 2015-12-03 11:30 +0100 |
| Message-ID | <qBzjc-3FV-15@gated-at.bofh.it> |
| In reply to | #161458 |
[Multipart message — attachments visible in raw view] — view raw
Hey! On Dec 1, 2015 7:42 AM, "Jape Person" <japers@comcast.net> wrote: > > Make remote CUPS printers available locally > Network Time Synchronization > > For several weeks I've been seeing this stop job notification for these two items frequently when rebooting or shutting down two of my four testing systems. > > The first notification counts all the way up to 1 min 30 sec before the shutdown scroll restarts. The second notification only counts for a few seconds before terminating. > > I'm a patient guy, but adding almost two minutes to almost every restart or shutdown procedure gets a bit tedious after a while. > Can you please annoy yourself once more and exactly tell what that start/stop job is for. I had a friend with same problem recently. He had the start/stop job for some uuidd... I found that he was missing the swap partition that he created while installation. There would definitely be a legitimate reason for that message to appear. > Suggestions, anyone? The complete message is really important. Perhaps, I would investigate. > I'm grateful for your time and any ideas you might provide. We love to gain experience. So thanks to you too. Good luck! Hima… irm20… 3 Dec 3:47pm To: irm2015006@iiita.ac.in Show details Delivery to the following recipient failed permanently: debian-user@lists.debian.com Technical details of permanent failure: DNS Error: Address resolution of lists.debian.com. failed: Domain name not found ----- Original message ----- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= iiita-ac-in.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to: references:date:message-id:subject:from:to :content-type; bh=mWJbLhjU2yuTzrRErSrHU3g2qROIOcCIFX/tyvssJVg=; b=KSV8UNGTTaggQPv4/CdT8WrU7VQfdpneOVQRCayXJvBs4pZ u+mNEzfjHujjy8N5vdx j6aX6Y+vFYF5VxcjO6pAU7OO9Ieg3e+ GaB43Fra+2IJ0ZeO+WajkpmV7f8v0MRX8TPQ+ X7Ae/3hXdFyt7TvdntFWJBk69pkESWp6fuK/qrEMsjc/ESPs9IRVYw6d9Gexb+t3cv5W ILvS1Utseo6jySEDgw07TmZDHMzbiE matljuEAi8rMyOIU5Zbhi91R+FoA1ETKakCLiQ 9g4hBeStvm3VtTBd+ VULmAvSSdO1AGr87VuY3i1nOU1+ MCYoxxihPiplJQkRw7zvBqTV G2SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= 1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=mWJbLhjU2yuTzrRErSrHU3g2qROIOcCIFX/tyvssJVg=; b=fRj4O68J4ZK/YqoKLcsSqm4LGSm+ KwoW0MdbticMdgIf2Q/D50+wU98WMRUH4ZXOR/22jQiOUUdNqn3VtRae3FpuoxPFiW5A NwsYJnWtHlc6e6+PfCX66XQXNxSj0smrx+HNDK vPPMyT0SMMGUmiVW2cCfTKyzGD2wPRAo/gWzvV5MdWtqhZ91VEm29ALu8Esf4vWUauQy wnsNOPAbfjWKA6K5NBpu5aZ4yFeufy CoS02Ldt1k/Ydmbn6Jhg6z80PEmHMed6tAPtaM jR0idGoFJLX9wOmg5ZJwJ/tv5/ZmxqeBvGUyaOASFuIKcjIvGoQN5U+ OPCSHtbcBG7hX qzbw== X-Gm-Message-State: ALoCoQn1GZhA/+9+ AGK1Y6SK43GAmRAtVaPrUMWoyH7K7i G1D9EuVFMjX7C8S7+xEpkcm+7CZBhS MIME-Version: 1.0 X-Received: by 10.182.131.194 with SMTP id oo2mr5264759obb.84.1449137833287; Thu, 03 Dec 2015 02:17:13 -0800 (PST) Received: by 10.202.67.66 with HTTP; Thu, 3 Dec 2015 02:17:13 -0800 (PST) Received: by 10.202.67.66 with HTTP; Thu, 3 Dec 2015 02:17:13 -0800 (PST) In-Reply-To: <565D0045.4040408@comcast.net> References: <565D0045.4040408@comcast.net> Date: Thu, 3 Dec 2015 15:47:13 +0530 Message-ID: <CANy4JSiHM7gDp6aaerdtHadpC7ZS H1npEpqBHoeXtpR0f7iFVQ@mail.gmail.com> Subject: Re: A stop job is running for... From: Himanshu Shekhar <irm2015006@iiita.ac.in> To: Jape Person < japers@comcast.net>, "debian-user@lists.debian.com" < debian-user@lists.debian.com> Content-Type: multipart/alternative; boundary= 089e01634b8ac8be000525fbb15f ▶ Show quoted text M
[toc] | [prev] | [next] | [standalone]
| From | Jape Person <japers@comcast.net> |
|---|---|
| Date | 2015-12-03 18:20 +0100 |
| Message-ID | <qBFHY-83M-13@gated-at.bofh.it> |
| In reply to | #161509 |
On 12/03/2015 05:22 AM, Himanshu Shekhar wrote: > The complete message is really important. Perhaps, I > would investigate. Hello! I did give the complete messages. Both start with A stop job is running for... The endings are Make remote CUPS printers available locally and Network Time Synchronization I've checked for CUPS and NTP errors in the logs and have found nothing. I presume that's because this happens during shutdown, but haven't done enough research to be sure. ---------------------------- Let me take this reply as an opportunity to ask two favors of you. First, please don't reply directly to me or CC me. I'm subscribed to the list, so I get all replies. Replies to messages here should be responses to the list -- unless a poster specifically asks to be copied. Second, please don't post html messages. They're very hard for people using textual interfaces to deal with, and the message I'm replying to was really hard to parse when creating a reply, even with Icedove, the mail client I'm using. (I do have Icedove set to display plain text. I could have it display html, but that would fly in the face of using it on this list.) Regards, JP
[toc] | [prev] | [next] | [standalone]
| From | Michael Biebl <biebl@debian.org> |
|---|---|
| Date | 2015-12-03 19:10 +0100 |
| Message-ID | <qBGul-98-3@gated-at.bofh.it> |
| In reply to | #161526 |
[Multipart message — attachments visible in raw view] — view raw
Am 03.12.2015 um 18:18 schrieb Jape Person: > A stop job is running for... > > The endings are > > Make remote CUPS printers available locally > > and > > Network Time Synchronization > > I've checked for CUPS and NTP errors in the logs and have found nothing. > I presume that's because this happens during shutdown, but haven't done > enough research to be sure. I would try the following as next steps. Before shutting down, start the debug shell on tty9 # systemctl start debug-shell.service Then on shutdown switch to tty9 and save the output of ps aux systemctl list-jobs systemctl status ntp cups-browsed and maybe attach an strace to the process(es) which don't want to die. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[toc] | [prev] | [next] | [standalone]
| From | Jape Person <japers@comcast.net> |
|---|---|
| Date | 2015-12-03 21:30 +0100 |
| Message-ID | <qBIFQ-1rh-13@gated-at.bofh.it> |
| In reply to | #161527 |
On 12/03/2015 01:00 PM, Michael Biebl wrote:
> Am 03.12.2015 um 18:18 schrieb Jape Person:
>> A stop job is running for...
>>
>> The endings are
>>
>> Make remote CUPS printers available locally
>>
>> and
>>
>> Network Time Synchronization
>>
>> I've checked for CUPS and NTP errors in the logs and have found nothing.
>> I presume that's because this happens during shutdown, but haven't done
>> enough research to be sure.
>
> I would try the following as next steps.
> Before shutting down, start the debug shell on tty9
> # systemctl start debug-shell.service
Okay, this didn't go as I expected. When I tried to switch to tty9 I got
a blank screen with a flashing underline cursor in the upper left corner.
I don't remember ever having looked at tty8 or tty9 before.
I tried to follow your directions as closely as possible by issuing the
above command from the root account on tty6.
After I switched back to the GUI on tty7 and initiated the shutdown I
was able to switch to tty9 where I was greeted by a root prompt from
which I issued the commands below.
>
> Then on shutdown switch to tty9 and save the output of
> ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 137820 5580 ? Ss 11:37 0:01 /sbin/init
root 2 0.0 0.0 0 0 ? S 11:37 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S 11:37 0:00
[ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S< 11:37 0:00
[kworker/0:0H]
root 7 0.0 0.0 0 0 ? S 11:37 0:07 [rcu_sched]
root 8 0.0 0.0 0 0 ? S 11:37 0:00 [rcu_bh]
root 9 0.0 0.0 0 0 ? S 11:37 0:00
[migration/0]
root 10 0.0 0.0 0 0 ? S 11:37 0:00
[watchdog/0]
root 11 0.0 0.0 0 0 ? S 11:37 0:00
[watchdog/1]
root 12 0.0 0.0 0 0 ? S 11:37 0:00
[migration/1]
root 13 0.0 0.0 0 0 ? S 11:37 0:00
[ksoftirqd/1]
root 15 0.0 0.0 0 0 ? S< 11:37 0:00
[kworker/1:0H]
root 16 0.0 0.0 0 0 ? S 11:37 0:00
[watchdog/2]
root 17 0.0 0.0 0 0 ? S 11:37 0:00
[migration/2]
root 18 0.0 0.0 0 0 ? S 11:37 0:00
[ksoftirqd/2]
root 20 0.0 0.0 0 0 ? S< 11:37 0:00
[kworker/2:0H]
root 21 0.0 0.0 0 0 ? S 11:37 0:00
[watchdog/3]
root 22 0.0 0.0 0 0 ? S 11:37 0:00
[migration/3]
root 23 0.0 0.0 0 0 ? S 11:37 0:00
[ksoftirqd/3]
root 25 0.0 0.0 0 0 ? S< 11:37 0:00
[kworker/3:0H]
root 26 0.0 0.0 0 0 ? S< 11:37 0:00 [khelper]
root 27 0.0 0.0 0 0 ? S 11:37 0:00 [kdevtmpfs]
root 28 0.0 0.0 0 0 ? S< 11:37 0:00 [netns]
root 29 0.0 0.0 0 0 ? S< 11:37 0:00 [perf]
root 30 0.0 0.0 0 0 ? S 11:37 0:00
[khungtaskd]
root 31 0.0 0.0 0 0 ? S< 11:37 0:00 [writeback]
root 33 0.0 0.0 0 0 ? SN 11:37 0:00 [ksmd]
root 34 0.0 0.0 0 0 ? SN 11:37 0:00
[khugepaged]
root 35 0.0 0.0 0 0 ? S< 11:37 0:00 [crypto]
root 36 0.0 0.0 0 0 ? S< 11:37 0:00
[kintegrityd]
root 37 0.0 0.0 0 0 ? S< 11:37 0:00 [bioset]
root 38 0.0 0.0 0 0 ? S< 11:37 0:00 [kblockd]
root 39 0.0 0.0 0 0 ? S< 11:37 0:00
[devfreq_wq]
root 41 0.0 0.0 0 0 ? S 11:37 0:00 [kswapd0]
root 42 0.0 0.0 0 0 ? S 11:37 0:00
[fsnotify_mark]
root 48 0.0 0.0 0 0 ? S< 11:37 0:00 [kthrotld]
root 50 0.0 0.0 0 0 ? S< 11:37 0:00
[ipv6_addrconf]
root 51 0.0 0.0 0 0 ? S< 11:37 0:00 [deferwq]
root 82 0.0 0.0 0 0 ? S< 11:37 0:00
[acpi_thermal_pm]
root 83 0.0 0.0 0 0 ? S 11:37 0:00
[irq/16-mmc0]
root 86 0.0 0.0 0 0 ? S< 11:37 0:00 [ata_sff]
root 92 0.0 0.0 0 0 ? S 11:37 0:00 [scsi_eh_0]
root 93 0.0 0.0 0 0 ? S< 11:37 0:00
[scsi_tmf_0]
root 94 0.0 0.0 0 0 ? S 11:37 0:00 [scsi_eh_1]
root 95 0.0 0.0 0 0 ? S< 11:37 0:00
[scsi_tmf_1]
root 96 0.0 0.0 0 0 ? S 11:37 0:00 [scsi_eh_2]
root 97 0.0 0.0 0 0 ? S< 11:37 0:00
[scsi_tmf_2]
root 98 0.0 0.0 0 0 ? S 11:37 0:00 [scsi_eh_3]
root 99 0.0 0.0 0 0 ? S< 11:37 0:00
[scsi_tmf_3]
root 100 0.0 0.0 0 0 ? S 11:37 0:00 [scsi_eh_4]
root 101 0.0 0.0 0 0 ? S< 11:37 0:00
[scsi_tmf_4]
root 102 0.0 0.0 0 0 ? S 11:37 0:00 [scsi_eh_5]
root 103 0.0 0.0 0 0 ? S< 11:37 0:00
[scsi_tmf_5]
root 110 0.0 0.0 0 0 ? S 11:37 0:00
[kworker/3:2]
root 118 0.0 0.0 0 0 ? S< 11:37 0:00
[kworker/0:1H]
root 121 0.0 0.0 0 0 ? S< 11:37 0:00
[kworker/2:1H]
root 153 0.0 0.0 0 0 ? S 11:37 0:00
[jbd2/sda1-8]
root 154 0.0 0.0 0 0 ? S< 11:37 0:00
[ext4-rsv-conver]
root 192 0.0 0.0 0 0 ? S< 11:37 0:00
[kworker/1:1H]
root 199 0.0 0.0 43756 6656 ? Ss 11:37 0:00
/lib/systemd/systemd-journald
root 207 0.0 0.0 0 0 ? S< 11:37 0:00
[kworker/3:1H]
root 209 0.0 0.0 0 0 ? S 11:37 0:00 [kauditd]
root 217 0.0 0.0 45504 5160 ? Ss 11:37 0:00
/lib/systemd/systemd-udevd
systemd+ 457 0.0 0.0 104216 2596 ? Ssl 11:37 0:00
/lib/systemd/systemd-timesyncd
root 509 0.0 0.0 0 0 ? S 11:37 0:00
[irq/25-mei_me]
root 525 0.0 0.0 0 0 ? S< 11:37 0:00 [kpsmoused]
root 526 0.0 0.0 0 0 ? S< 11:37 0:00 [ktpacpid]
root 541 0.0 0.0 0 0 ? S< 11:37 0:00 [cfg80211]
root 546 0.2 0.0 0 0 ? S 11:37 0:35
[irq/27-iwlwifi]
root 557 0.0 0.0 0 0 ? S 11:37 0:00
[kworker/2:3]
root 574 0.0 0.0 0 0 ? S< 11:37 0:00
[kvm-irqfd-clean]
root 581 0.0 0.0 0 0 ? S< 11:37 0:00 [iwlwifi]
root 663 0.0 0.1 91504 9404 ? Ss 11:37 0:00
/usr/sbin/cupsd -l
root 715 0.0 0.1 250812 8680 ? Ssl 11:37 0:00
/usr/sbin/cups-browsed
lp 993 0.0 0.0 78772 5584 ? S 11:38 0:00
/usr/lib/cups/notifier/dbus dbus://
root 1114 0.0 0.0 43828 3048 ? Ss 11:38 0:00
wpa_supplicant -B -i wlan0 -c /var/lib/wicd/configurations/586d8facceba
-Dwext
lp 1188 0.0 0.0 78772 5584 ? S 11:38 0:00
/usr/lib/cups/notifier/dbus dbus://
root 1234 0.0 0.0 15020 1720 ? Ss 11:38 0:00
/sbin/dhclient -v wlan0
root 2796 0.0 0.0 0 0 ? S 11:52 0:00
[kworker/1:1]
root 2973 0.0 0.0 0 0 ? S 11:53 0:00
[kworker/2:0]
root 4263 0.0 0.0 0 0 ? S 12:14 0:01
[kworker/0:0]
root 4281 0.0 0.0 0 0 ? S 12:15 0:00
[kworker/1:2]
root 4288 0.0 0.0 0 0 ? S 12:15 0:00
[kworker/3:0]
root 9156 0.0 0.0 0 0 ? S 13:40 0:00
[kworker/0:2]
root 11116 0.0 0.0 0 0 ? S 14:15 0:01
[kworker/u16:1]
root 11832 0.0 0.0 0 0 ? S 14:28 0:00
[kworker/u16:3]
root 13565 0.0 0.0 0 0 ? S 14:47 0:00
[kworker/u16:0]
root 13782 0.0 0.0 0 0 ? S 14:51 0:00
[kworker/3:1]
root 13891 0.0 0.0 21564 4648 tty9 Ss 14:52 0:00 /bin/bash
root 13918 0.0 0.0 0 0 ? S 14:52 0:00
[kworker/1:0]
root 13923 0.0 0.0 0 0 ? S 14:52 0:00
[kworker/0:1]
root 13928 0.0 0.0 0 0 ? S 14:52 0:00
[kworker/2:1]
root 13950 0.0 0.0 0 0 ? S 14:52 0:00
[kworker/3:3]
root 13953 0.0 0.0 0 0 ? S 14:52 0:00
[kworker/2:2]
root 13954 0.0 0.0 0 0 ? S 14:52 0:00
[kworker/0:3]
root 13959 0.0 0.0 0 0 ? S 14:52 0:00
[kworker/0:4]
root 14014 0.0 0.0 0 0 ? S 14:52 0:00
[kworker/2:4]
root 14020 0.0 0.0 0 0 ? S 14:52 0:00
[kworker/u16:2]
root 14027 0.0 0.0 34216 2768 tty9 R+ 14:53 0:00 ps aux
> systemctl list-jobs
JOB UNIT TYPE STATE
1234 local-fs.target stop waiting
1198 dbus.socket stop waiting
1197 cups.path stop waiting
1223 systemd-ask-password-wall.path stop waiting
1143 systemd-backlight@backlight:acpi_video0.service stop waiting
1149 systemd-tmpfiles-setup-dev.service stop waiting
1141 local-fs-pre.target stop waiting
1168 cups.service stop waiting
1175 time-sync.target stop waiting
1231 paths.target stop waiting
1238 cryptsetup.target stop waiting
1125 final.target start waiting
1155 slices.target stop waiting
1178 avahi-daemon.socket stop waiting
1227 systemd-remount-fs.service stop waiting
1142 systemd-ask-password-console.path stop waiting
1192 cups-browsed.service stop running
1209 rpcbind.socket stop waiting
1113 poweroff.target start waiting
1174 systemd-tmpfiles-setup.service stop waiting
1150 systemd-random-seed.service stop waiting
1204 basic.target stop waiting
1114 systemd-poweroff.service start waiting
1232 system-systemd\x2dbacklight.slice stop waiting
1123 run-user-0.mount stop waiting
1222 networking.service stop waiting
1233 systemd-backlight@backlight:intel_backlight.service stop waiting
1122 swap.target stop waiting
1171 systemd-networkd-resolvconf-update.path stop waiting
1218 nfs-common.service stop waiting
1145 systemd-timesyncd.service stop waiting
1115 umount.target start waiting
1147 cups.socket stop waiting
1128 shutdown.target start waiting
1219 systemd-modules-load.service stop waiting
1220 sockets.target stop waiting
1170 syslog.socket stop waiting
1116 run-user-1000.mount stop waiting
1130 uuidd.socket stop waiting
1216 user.slice stop waiting
1217 systemd-sysctl.service stop waiting
1188 sysinit.target stop waiting
1124 run-user-117.mount stop waiting
43 jobs listed.
> systemctl status ntp cups-browsed
>
* ntp.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
* cups-browsed.service - Make remote CUPS printers available locally
Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled;
vendor preset: enabled)
Active: deactivating (stop-sigterm) since Thu 2015-12-03 14:52:34
EST; 57s ago
Main PID: 715 (cups-browsed)
CGroup: /system.slice/cups-browsed.service
`-715 /usr/sbin/cups-browsed
Dec 03 11:37:57 trick systemd[1]: Started Make remote CUPS printers
available locally.
Dec 03 14:52:34 trick systemd[1]: Stopping Make remote CUPS printers
available locally...
> and maybe attach an strace to the process(es) which don't want to die.
>
I'm going to have to do a little reading on this utility to figure out
how to use it.
Is there any particlar set of commands and / or options I should use
with it to get the results you feel might be useful? I gather that I
open a terminal emulator or use a tty, log in as root, get the PIDs of
the recalcitrant processes, and attach an strace (set to record its
output to a file) to each of them, then initiate the shutdown?
Sorry that I'm not used to doing stuff like this, but I'm willing to
give it a try if it can be helpful.
Thanks for your help, Michael. I'm a fan of your work.
[toc] | [prev] | [next] | [standalone]
| From | Michael Biebl <biebl@debian.org> |
|---|---|
| Date | 2015-12-03 22:10 +0100 |
| Message-ID | <qBJiy-1Vy-15@gated-at.bofh.it> |
| In reply to | #161531 |
[Multipart message — attachments visible in raw view] — view raw
Am 03.12.2015 um 21:21 schrieb Jape Person: > /usr/sbin/cupsd -l > root 715 0.0 0.1 250812 8680 ? Ssl 11:37 0:00 > /usr/sbin/cups-browsed > lp 993 0.0 0.0 78772 5584 ? S 11:38 0:00 > /usr/lib/cups/notifier/dbus dbus:// > root 1114 0.0 0.0 43828 3048 ? Ss 11:38 0:00 > wpa_supplicant -B -i wlan0 -c /var/lib/wicd/configurations/586d8facceba > -Dwext > lp 1188 0.0 0.0 78772 5584 ? S 11:38 0:00 > /usr/lib/cups/notifier/dbus dbus:// > root 1234 0.0 0.0 15020 1720 ? Ss 11:38 0:00 > /sbin/dhclient -v wlan0 That process output is interesting. Two issues that come to mind here: a/ cups-browsed.service declares a dependency on avahi-daemon.service. So it should be stopped before avahi-daemon. But apparently you don't have any avahi-daemon process anymore. Would be interesting to find out, why avahi-daemon.service is stopped before cups-browsed. Can you paste the systemctl cat avahi-daemon.service cups-browsed.service output b/ you use wicd. I suspect wicd is stopped (too) early during shutdown and tears down the network connection. Maybe that's related as well. I wonder if we should take this off list now. Not sure if our debugging session is interesting to the readers of this mailing list. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[toc] | [prev] | [next] | [standalone]
| From | Chris Bannister <cbannister@slingshot.co.nz> |
|---|---|
| Date | 2015-12-04 10:20 +0100 |
| Subject | Systemd debugging (was ... Re: A stop job is running for...) |
| Message-ID | <qBUH1-Lu-25@gated-at.bofh.it> |
| In reply to | #161532 |
On Thu, Dec 03, 2015 at 10:07:01PM +0100, Michael Biebl wrote: > Two issues that come to mind here: > a/ cups-browsed.service declares a dependency on avahi-daemon.service. > So it should be stopped before avahi-daemon. But apparently you don't > have any avahi-daemon process anymore. > Would be interesting to find out, why avahi-daemon.service is stopped > before cups-browsed. > Can you paste the systemctl cat avahi-daemon.service cups-browsed.service > output > > b/ you use wicd. I suspect wicd is stopped (too) early during shutdown > and tears down the network connection. Maybe that's related as well. > > I wonder if we should take this off list now. Not sure if our debugging > session is interesting to the readers of this mailing list. Au contraire, not knowing much about systemd myself, and having wrestled with a postgreSQL upgrade on a raspberry PI running raspbian, I'm keen on any troubleshooting/bug hunting tips I can get. This may have had something to do it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755894 -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X
[toc] | [prev] | [next] | [standalone]
| From | Rick Thomas <rbthomas@pobox.com> |
|---|---|
| Date | 2015-12-03 19:30 +0100 |
| Message-ID | <qBGNH-fM-11@gated-at.bofh.it> |
| In reply to | #161526 |
Hi JP
On Dec 3, 2015, at 9:18 AM, Jape Person <japers@comcast.net> wrote:
> On 12/03/2015 05:22 AM, Himanshu Shekhar wrote:
>> The complete message is really important. Perhaps, I
>> would investigate.
>
> Hello!
>
> I did give the complete messages. Both start with
>
> A stop job is running for...
>
> The endings are
>
> Make remote CUPS printers available locally
>
> and
>
> Network Time Synchronization
>
> I've checked for CUPS and NTP errors in the logs and have found nothing. I presume that's because this happens during shutdown, but haven't done enough research to be sure.
>
> ----------------------------
One thing that might help (you may already have done it, but it can’t hurt to ask) is to make the systemd journal persistent. This way you can examine after the fact the log messages and other journal stuff that occur during a system shutdown/restart. You do that by doing
sudo mkdir /var/log/journal # make the journal persistent
Then reboot. After that you can do
sudo journalctl —list-boots
To see a list of boot numbers (32-digit hex IDs) for which the entire journal is available along with the date/times of start and end.
To examine the journal for a particular boot number, use
sudo journalctl —boot=<boot number>
This is all covered in the journalctl man page, which you’ve probably read, but you might have missed those details.
Another hint about the systemd Journal (and log files in general): when searching for messages relating to, for example, the ntp daemon, it helps to use the “-i” (Ignore case) option. Sometimes ntp is spelled NTP in log messages. Same goes for CUPS.
Enjoy!
Rick
[toc] | [prev] | [next] | [standalone]
| From | Jape Person <japers@comcast.net> |
|---|---|
| Date | 2015-12-03 22:20 +0100 |
| Message-ID | <qBJse-1YU-29@gated-at.bofh.it> |
| In reply to | #161528 |
On 12/03/2015 01:23 PM, Rick Thomas wrote: > Hi JP > > On Dec 3, 2015, at 9:18 AM, Jape Person <japers@comcast.net> wrote: > >> On 12/03/2015 05:22 AM, Himanshu Shekhar wrote: >>> The complete message is really important. Perhaps, I would >>> investigate. >> >> Hello! >> >> I did give the complete messages. Both start with >> >> A stop job is running for... >> >> The endings are >> >> Make remote CUPS printers available locally >> >> and >> >> Network Time Synchronization >> >> I've checked for CUPS and NTP errors in the logs and have found >> nothing. I presume that's because this happens during shutdown, but >> haven't done enough research to be sure. >> >> ---------------------------- > > One thing that might help (you may already have done it, but it can’t > hurt to ask) is to make the systemd journal persistent. This way you > can examine after the fact the log messages and other journal stuff > that occur during a system shutdown/restart. You do that by doing > > sudo mkdir /var/log/journal # make the journal persistent > > Then reboot. After that you can do > > sudo journalctl —list-boots > > To see a list of boot numbers (32-digit hex IDs) for which the entire > journal is available along with the date/times of start and end. > > To examine the journal for a particular boot number, use > > sudo journalctl —boot=<boot number> > > This is all covered in the journalctl man page, which you’ve probably > read, but you might have missed those details. > > Another hint about the systemd Journal (and log files in general): > when searching for messages relating to, for example, the ntp daemon, > it helps to use the “-i” (Ignore case) option. Sometimes ntp is > spelled NTP in log messages. Same goes for CUPS. > > Enjoy! Rick > Thanks, Rick. I knew about the issue searching for different cases, and was vaguely aware that the journal could be made persistent. I don't actually see that particular info in the man page. Maybe I'll try to get some sleep and reread it more carefully. Thanks again.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2015-12-02 17:00 +0100 |
| Message-ID | <qBhZ1-Jp-29@gated-at.bofh.it> |
| In reply to | #161453 |
On Wed 02 Dec 2015 at 11:06:09 (+0000), Martin Read wrote: > On 02/12/15 03:07, James P. Wallen wrote: > >Thanks for your response, Sven. It's nice to know that someone else has > >seen this type of problem. I was thinking that this could be > >self-inflicted. Perhaps that's a little less likely now. > > > >So, is this behavior controlled by systemd? > > > >I'm not trying to start a fracas. I'm really interested. What I'm asking > >is, do I need to start poring over systemd documentation to see if there > >might be a way to control this behavior? > > If a stop job is taking two minutes, that suggests that the service > has one or more ExecStop lines defined in its service unit and that > one of those commands is taking an unduly long time to complete for > some reason. > > The default and per-service timeout values for stopping a service > (after which systemd gives up and sends fatal signals to all of the > service's processes) are configurable; see the > systemd-system.conf(5) and systemd.service(5) man pages for details. I have observed behaviour where, when the time limit of 90 seconds is reached, the limit increases by another 90 seconds and nothing else happens (for hours). eg [ <*> ] A stop job is running for Manage, Install and Generate Color Profiles (34min 54s / 36min)_ Fortunately, that hasn't happened for a few months. It's very embarrassing when my laptop takes longer to close down than my wife's W10. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Jape Person <japers@comcast.net> |
|---|---|
| Date | 2015-12-02 18:10 +0100 |
| Message-ID | <qBj4L-1FO-27@gated-at.bofh.it> |
| In reply to | #161460 |
On 12/02/2015 10:49 AM, David Wright wrote: > On Wed 02 Dec 2015 at 11:06:09 (+0000), Martin Read wrote: >> On 02/12/15 03:07, James P. Wallen wrote: >>> Thanks for your response, Sven. It's nice to know that someone else has >>> seen this type of problem. I was thinking that this could be >>> self-inflicted. Perhaps that's a little less likely now. >>> >>> So, is this behavior controlled by systemd? >>> >>> I'm not trying to start a fracas. I'm really interested. What I'm asking >>> is, do I need to start poring over systemd documentation to see if there >>> might be a way to control this behavior? >> >> If a stop job is taking two minutes, that suggests that the service >> has one or more ExecStop lines defined in its service unit and that >> one of those commands is taking an unduly long time to complete for >> some reason. >> >> The default and per-service timeout values for stopping a service >> (after which systemd gives up and sends fatal signals to all of the >> service's processes) are configurable; see the >> systemd-system.conf(5) and systemd.service(5) man pages for details. > > I have observed behaviour where, when the time limit of 90 seconds is > reached, the limit increases by another 90 seconds and nothing else > happens (for hours). eg > > [ <*> ] A stop job is running for Manage, Install and Generate Color Profiles (34min 54s / 36min)_ > > Fortunately, that hasn't happened for a few months. It's very > embarrassing when my laptop takes longer to close down than my > wife's W10. > > Cheers, > David. > > Now *that* would be annoying. It's interesting that I have been unable to find bug reports about this. I guess it might be kind of hard to figure which packages to file a report against. I can imagine there might be a bit of finger-pointing between the systemd folks and the developers and maintainers of the various packages services when unfortunate interactions via the service units are hard to tease out. It is at least nice to have a way to force an errant service to shut down -- assuming the scheme works. I haven't experimented yet, but that's on the schedule for later today. I suppose it's unlikely that forcing a service like CUPS or NTP to shut down will lead to other problems. I hope.
[toc] | [prev] | [next] | [standalone]
| From | Michael Biebl <biebl@debian.org> |
|---|---|
| Date | 2015-12-02 18:20 +0100 |
| Message-ID | <qBjeq-1JE-17@gated-at.bofh.it> |
| In reply to | #161462 |
[Multipart message — attachments visible in raw view] — view raw
Am 02.12.2015 um 18:05 schrieb Jape Person: > On 12/02/2015 10:49 AM, David Wright wrote: >> I have observed behaviour where, when the time limit of 90 seconds is >> reached, the limit increases by another 90 seconds and nothing else >> happens (for hours). eg >> >> [ <*> ] A stop job is running for Manage, Install and Generate Color >> Profiles (34min 54s / 36min)_ >> >> Fortunately, that hasn't happened for a few months. It's very >> embarrassing when my laptop takes longer to close down than my >> wife's W10. Sounds like it could be hard to reproduce indeed. > Now *that* would be annoying. In case you run into such a situation again, where a service is blocking the shutdown you can of course just use force and pull the plug or use sysrq b. But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times. systemd then will initiate a forced shutdown. See [1]. Regards, Michael http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[toc] | [prev] | [next] | [standalone]
| From | Jape Person <japers@comcast.net> |
|---|---|
| Date | 2015-12-02 19:00 +0100 |
| Message-ID | <qBjR9-20s-29@gated-at.bofh.it> |
| In reply to | #161463 |
On 12/02/2015 12:17 PM, Michael Biebl wrote: > Am 02.12.2015 um 18:05 schrieb Jape Person: >> On 12/02/2015 10:49 AM, David Wright wrote: >>> I have observed behaviour where, when the time limit of 90 seconds is >>> reached, the limit increases by another 90 seconds and nothing else >>> happens (for hours). eg >>> >>> [ <*> ] A stop job is running for Manage, Install and Generate Color >>> Profiles (34min 54s / 36min)_ >>> >>> Fortunately, that hasn't happened for a few months. It's very >>> embarrassing when my laptop takes longer to close down than my >>> wife's W10. > > Sounds like it could be hard to reproduce indeed. > >> Now *that* would be annoying. > > In case you run into such a situation again, where a service is blocking > the shutdown you can of course just use force and pull the plug or use > sysrq b. > But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times. > systemd then will initiate a forced shutdown. See [1]. > > Regards, > Michael > > > http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT > Seven times. How lucky! Heh. Thank you, Michael. Do you think it's better just force the shutdown than to rummage around in the service unit files? I'm loath to edit system configuration files unless it's to configure something like smartmontools or some such -- you know, something that is more ordinarily edited in order to get it to do some specific job. I guess that argument could apply to service units, but I'm not used to this stuff, yet. Thanks again, JP
[toc] | [prev] | [next] | [standalone]
| From | Michael Biebl <biebl@debian.org> |
|---|---|
| Date | 2015-12-02 20:10 +0100 |
| Message-ID | <qBkWR-2Tg-5@gated-at.bofh.it> |
| In reply to | #161465 |
[Multipart message — attachments visible in raw view] — view raw
Am 02.12.2015 um 18:58 schrieb Jape Person: > On 12/02/2015 12:17 PM, Michael Biebl wrote: >> In case you run into such a situation again, where a service is blocking >> the shutdown you can of course just use force and pull the plug or use >> sysrq b. >> But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times. >> systemd then will initiate a forced shutdown. See [1]. .. > Do you think it's better just force the shutdown than to rummage around > in the service unit files? I'm loath to edit system configuration files > unless it's to configure something like smartmontools or some such -- > you know, something that is more ordinarily edited in order to get it to > do some specific job. > > I guess that argument could apply to service units, but I'm not used to > this stuff, yet. In your case it seems to happen much more often, that the service does not shutdown in a timely manner. So this should actually be investigated properly. My remark regarding using a forced shutdown via ctrl+alt+-del is only supposed to be a fix for very rare cases. I also wouldn't consider it a proper fix to simply decrease the shutdown timeout of the affected service. That's a hack at best. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[toc] | [prev] | [next] | [standalone]
| From | Jape Person <japers@comcast.net> |
|---|---|
| Date | 2015-12-02 20:30 +0100 |
| Message-ID | <qBlge-31N-21@gated-at.bofh.it> |
| In reply to | #161469 |
On 12/02/2015 02:04 PM, Michael Biebl wrote: > Am 02.12.2015 um 18:58 schrieb Jape Person: >> On 12/02/2015 12:17 PM, Michael Biebl wrote: >>> In case you run into such a situation again, where a service is blocking >>> the shutdown you can of course just use force and pull the plug or use >>> sysrq b. >>> But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times. >>> systemd then will initiate a forced shutdown. See [1]. > > .. > >> Do you think it's better just force the shutdown than to rummage around >> in the service unit files? I'm loath to edit system configuration files >> unless it's to configure something like smartmontools or some such -- >> you know, something that is more ordinarily edited in order to get it to >> do some specific job. >> >> I guess that argument could apply to service units, but I'm not used to >> this stuff, yet. > > In your case it seems to happen much more often, that the service does > not shutdown in a timely manner. So this should actually be investigated > properly. > Aye, there's the rub! The phrase "investigated properly" would seem to indicate that someone who knows what s/he's doing would be performing the analysis. How about me doing my usual thumb-fingered job on it, and then coming back here for advice when I have enough bruises on my forehead to prove that I have indeed been to the wall? ;-) > My remark regarding using a forced shutdown via ctrl+alt+-del is only > supposed to be a fix for very rare cases. > > I also wouldn't consider it a proper fix to simply decrease the shutdown > timeout of the affected service. That's a hack at best. > > Michael > > Yes, I was beginning to be dimly aware. I don't like futzing around with files in system or root owned areas unless they are designed to be futzed with. Not only because I don't like having my modifications overwritten during upgrades (and I do always choose to write the maintainer's upgrade over my modification and then change it again as necessary), but also because I don't like knowing that all sorts of weird stuff might happen if I do something particularly stupid. I am, after all, very experienced and accomplished at being particularly stupid. It's why I run testing. I like having a plausible explanation, other than my own ineptitude, for having things go wrong. Have a nice day! JP
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.debian.user
csiph-web