ব্যবহারকারীর সেশন সি 2 এর জন্য একটি স্টপ জব চলছে


56

নিম্নলিখিত বার্তাটি প্রায়শই প্রতিবার উপস্থিত হয় যখন আমি আমার কম্পিউটারটি বন্ধ করি:

A stop job is running for Session c2 of user ... (1min 30s)

এটি 1 মিনিট 30 এর জন্য অপেক্ষা করে তারপরে শাটডাউন প্রক্রিয়াটি চালিয়ে যায়। আমি এই সিস্টেমেড শাটডাউন ডায়াগনোসিস গাইডটি অনুসরণ করি এবং শাটডাউন-লগ.টিএসটি (আমি খুব লম্বা হওয়ার কারণে এখানে সরাসরি লগটি পেষ্ট করতে পারি না) get দুর্ভাগ্যক্রমে, আমি নিজের দ্বারা লগ বুঝতে পারি না। আমার সিস্টেমটি কীভাবে সঠিকভাবে বন্ধ হচ্ছে না তা জানতে কেউ আমাকে সাহায্য করতে পারে?

আমি কার্নেল দিয়ে আর্চ লিনাক্স চালাই 4.4.5-1-ARCH, আমার systemdসংস্করণটি 229-3

সংযোজন 1: আমি পর্যবেক্ষণ করি যে যতবার আমি লগআউট করি এবং তারপরে লগইন স্ক্রিন থেকে আমার কম্পিউটারটি বন্ধ করে দিই, এটি বার্তাটি পায় না A stop job is running...। আমি অনেকবার শাটডাউন করার আগে লগআউট করার চেষ্টা করেছি, তাই আমি মনে করি এটি যথাযথভাবে ঘটে না। আশা করি তথ্য সাহায্য করতে পারে।

সংযোজন 2: এটি সর্বদা সেশন সি 2 থাকে যা শাটডাউন ঝুলিয়ে রাখে। @ এন.এস্ট অনুসারে, আমি শাটডাউন সমস্যাগুলি আবার ডায়াগনোস করে দেখেছি এবং loginctl session-status c2পরিবর্তে সংরক্ষণ করেছি dmesgতবে এরপরে কিছুই নেই shutdown-log.txt। আমি প্রতিস্থাপিত loginctl session-status c2দ্বারা systemd-cglsএবং নিচের লগ করেছেন:

Control group /:
-.slice
└─init.scope
  ├─   1 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
  ├─1069 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
  ├─1071 /bin/sh /usr/lib/systemd/system-shutdown/debug.sh reboot
  └─1074 systemd-cgls

কোন ধারনা?

দ্রষ্টব্য: আমি কার্নেলটিতে আপডেট হওয়ার পরে 4.6.4-1-ARCHএবং systemd 230-7ত্রুটিটি আর ঘটেনি।


দুর্ভাগ্যক্রমে আপনি যে dmesgআউটপুটটি আটকিয়েছেন তা খুব তথ্যপূর্ণ নয় - এটি আপনি যখন শাটডাউন বোতামটি (সিস্টেম বুটআপের 3030 সেকেন্ড) আঘাত করবেন তখন ওয়াইফাই সংযোগ বিচ্ছিন্ন করে দেখায় এবং তারপরে 1m30s টাইমারটির মেয়াদ শেষ না হওয়া পর্যন্ত এবং সিস্টেমটি বন্ধ হওয়া অবধি (3139 সেকেন্ডে) প্রদর্শিত হবে।
n.st

1
সেই অশুভ সেশন সি 2 এ কী চলছে তা যাচাই করতে যা নিজে থেকে শেষ হচ্ছে না, ব্যবহার করুন loginctl session-status c2। আমি নিশ্চিত না যে আপনি এখনও শাটডাউন চলাকালীন কোনও গেটটিতে যেতে পারেন, তবে "একটি স্টপ জব চলছে ..." পপ আপ হয়ে গেলে Ctrl + Alt + F2 এ আঘাত করার চেষ্টা করুন। যদি এটি কাজ করে তবে আপনি লগইন প্রম্পট পাবেন এবং loginctlকমান্ডটি ব্যবহার করতে সক্ষম হবেন । আপনি যদি লগইন প্রম্পট না পান তবে আপনি যে একই পদক্ষেপের জন্য ব্যবহার করেছেন সেগুলি অনুসরণ করুন dmesg, তবে loginctl session-status c2পরিবর্তে আউটপুট সংরক্ষণ করুন । (
এগুলি সবই ধরে নিচ্ছে

1
আপনি এই হ্যাক করে (অস্থায়ী) সমাধান পেতে পারে: তৈরি /etc/sysctl.d/50-coredump.confবিষয়বস্তু সঙ্গে: kernel.core_pattern=core, সূত্র: github.com/systemd/systemd/issues/1615#issuecomment-203507283
Runium


2
@aurelien এটি কি সর্বদা সি 2 এর ফলে টাইমারকে শাটডাউন করার কারণ হয়? যদি তা হয় তবে আপনি শাটডাউন সমস্যাগুলি আবার নির্ণয় করতে পারেন এবং loginctl session-status c2পরিবর্তে সঞ্চয় করতে পারেন dmesg
n.st

উত্তর:


45

এই সমস্যার সমাধানের জন্য এই সময়সীমাটি /etc/systemd/system.conf90 এর দশকে হ্রাস করে উদাহরণস্বরূপ 10 সেকেন্ড করতে হবে:

DefaultTimeoutStopSec=10s

এবং পরিবর্তনগুলি করার পরে টার্মিনালে নিম্নলিখিত কমান্ডটি চালান

$ systemctl daemon-reload

9
এটি সমস্যার ব্যাখ্যা দেয় না বা সমাধান করে না, 10s এর জন্যও অপেক্ষা করে এবং ক্লিন শাটডাউন না করা মোটেও দুর্দান্ত নয়
jcora

আমি কি এমন কোন কাজ করছি যে 10s এর বেশি সময় লাগবে?
জারেড চু

10

এই সমস্যাটির অনেকগুলি কারণ থাকতে পারে, সুতরাং নির্দিষ্ট উত্তরগুলি খুব ভাল কাজ করে না। সমস্যা সমাধানের জন্য এটি ব্যবহার করে দেখুন:

  1. "একটি স্টপ জব চলছে সেশন সি 2 এর জন্য চলছে ..." বার্তাটি শাটডাউনে প্রদর্শিত হবে এবং শাটডাউন শেষ হয়ে গেলে পুনরায় বুট করুন
  2. journalctl -p5একটি টার্মিনালে চালান এবং ENDসিস্টেমড জার্নালটির শেষের দিকে যেতে টিপুন ( -p5প্রচুর আবর্জনা ফিল্টার করে)
  3. টিপে অনুসন্ধান শুরু করুন /এবং অনুসন্ধান শব্দটি প্রবেশ করুনtimed out. Killing.
  4. SHIFT+Nবারবার টিপে পিছনে অনুসন্ধান করুন
  5. প্রতিটি ম্যাচের নীচের লাইনটি আপনাকে জানায় যে কোন অ্যাপ্লিকেশনটি খারাপ আচরণ করেছে:Killing process 1234 (jack_thru) with signal SIGKILL.

যদি এটি সর্বদা একই অ্যাপ্লিকেশন হয় তবে আপনি এটি অনুসন্ধান করতে এবং এটি শাটডাউনে কেন থামানো হয়নি তা জানতে চান। অন্যথায় সমস্যাটি সমাধান করা আরও জটিল হতে পারে তবে আপনি এখনও একটি ইঙ্গিত পেতে পারেন।

শুভকামনা! :)


1
এই সঠিক উত্তরের জন্য ধন্যবাদ। আমি এটি ব্যবহার করে এটি ব্যবহার করতে পেরেছিলাম যে আমার ক্ষেত্রে ফেডোরা 30 "এলপিএফ" বিজ্ঞপ্তিগুলির কারণ ছিল এবং এলপিএফ-গুই-তে নথিভুক্ত বিজ্ঞপ্তি | বিজ্ঞপ্তিগুলি সক্ষম করুন।
vk5tu

5

আমার একই সমস্যা ছিল, অনুসন্ধান করে আমি আর্ক লিনাক্সের একটি রেডডিট ফোরামে একটি পোস্ট পেয়েছি।

এই সমাধানটি আমার জন্য কাজ করে https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for_session_c2_of_user/d17th3u

নজরদারি ইনস্টল করুন

# pacman -S watchdog

এবং তারপরে বুটে পরিষেবাটি শুরু করুন:

# systemctl enable watchdog.service

আর বার্তাটি না দেখার জন্য পরিষেবাটি শুরু করুন

# systemctl start watchdog.service

আমি এই https://gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca3 এর জন্য একটি সংক্ষিপ্তসার তৈরি করেছি


আমি আপনার গাইড অনুসরণ করেছিলাম, কিন্তু এটি সমস্যার সমাধান করে না। যাহোক তোমাকে ধন্যবাদ.
ম্যাকঙ্গুয়েন

2
এই ফিক্সের সাথে অন্য কোনও প্রভাব আছে কি? স্পষ্টতই watchdog হার্ডওয়্যার সিস্টেমটিকে পুনরায় সেট করবে যদি এটি অন্য পরীক্ষাগুলি পিছিয়ে বা ব্যর্থ হয়। সুতরাং যখন প্রশ্নের সময়সীমাটি ঘটে তখন ওয়াচডগ কম্পিউটার পুনরায় সেট করবে। আমি অবাক হয়েছি যদি সিস্টেমটি আরও পরিষ্কারভাবে শাটডাউন করে তবে আমরা যদি অন্য উত্তর অনুসারে সময়সীমাটি হ্রাস করি । আমি আরও ভাবছি যে watchdogঅন্য, অযাচিত পরিস্থিতিতে পুনরায় সেট করতে বাধ্য করবে কিনা ।
স্পারহক

আমি আপনার ম্যান পৃষ্ঠা পড়ছি । আমি মনে করি যে ওয়াচডগ রিসেটটিকে লিনাক্স কার্নেলকে বলেছে যে সবকিছু ঠিক আছে, তা আটকাতে বাধা দেয়
ডিয়েগো জুলিয়াও

> এটি / dev / ওয়াচডোগ খুলবে এবং প্রায়শই প্রতি মিনিটে একবার কর্নেলটিকে পুনরায় সেট করা থেকে রক্ষা করতে যথেষ্ট লিখতে থাকে।
দিয়েগো জুলিয়াও

ওপেনসুএসে ওয়াচডগ নামে কোনও প্যাকেজ নেই, সুতরাং এটি সত্যিই আমাকে সাহায্য করে না :(
ডেভিড

4

আমি এখানে এমন একটি সমাধান পেয়েছি যা ডিবিয়ান 9 এর সাথে আমার কাছে ভিবক্সে কাজ করেছিল। আমি শাটডাউন বা পুনঃসূচনাতে সাধারণত 120 সেকেন্ডের বিলম্ব পাচ্ছিলাম।

https://forums.kali.org/showthread.php?32498-Delay-90-seconds-on-shutdown

আয়রণম্যান যেমন বলেছেন:

সমাধানটি শেল এবং "এখনই বন্ধ" খুলতে হবে তারপরে মেশিনটি আবার আসার পরে একটি "রিবুট" করুন এবং বার্তাটি চলে যায় এবং ভবিষ্যতের পুনরায় বুটগুলি আর স্তব্ধ হয় না।

আমি "সুডো শাটডাউন এখন" ব্যবহার করেছি এবং পুনরায় চালু করার বিলম্ব এখন শেষ। খুব সহজ বলে মনে হচ্ছে তবে এটি আমার (এবং অন্যদের) পক্ষে কাজ করেছে।

আছে HTH


8
এই উত্তরটিতে এতগুলি উত্সাহ কেন? এটি আমার পক্ষে কার্যকর হয়নি এবং এটি কেন কাজ করবে সে সম্পর্কে কোনও ধারণা দেয় না।
রদ্রিগো

আমার জন্য কাজ করেছেন, তবে এটি কেন হয়নি তা এখনও পরিষ্কার নয়।
pstryk

3

কালী [2017.01] তে একই রকম সমস্যা দেখা দিয়েছিল, বিকল্প লগআউট বিলম্বের দ্বারা প্রদর্শিত:

"ব্যবহারকারীর ডেবিয়ান-জিডিএম এর সেশন সি 1 এর জন্য একটি স্টপ জব চলছে"

"ইউআইডি 132-র জন্য ইউজার ম্যানেজারের জন্য একটি স্টপ জব চলছে"

আমি NetworkManagerশাটডাউন করার আগে প্রথমে থামিয়ে বা এটি অক্ষম করে একটি ত্রুটি থেকে মুক্তি দিতে সক্ষম হয়েছি :

# To get rid of: "A stop job is running for User manager for UID 132"
systemctl disable NetworkManager 
systemctl stop NetworkManager 

রিবুট করার সময় এটি সম্ভবত ঠিক করা বা অন্য কোনও উপায়ে রাখা উচিত।

অন্য বিলম্ব হিসাবে, আমি সফল হইনি। দেখে মনে হচ্ছে এটি জিডিএম ( জিনোম ডিসপ্লে ম্যানেজার ) এর সাথে সম্পর্কিত হতে পারে pulseaudioবা dbus। সুতরাং যেহেতু আমি সমস্যাটি বিচ্ছিন্ন করতে সক্ষম ছিলাম না, একমাত্র উপায় ছিল অন্যান্য পোস্টগুলিতে ইতিমধ্যে উল্লিখিত হিসাবে DefaultTimeout*Sec=5sপ্রবেশগুলি সেট করা system.conf

তদন্ত করা হতে পারে এমন অন্যান্য বিষয়গুলি এখানে দেখানো হয়েছে:

# systemctl --state=masked --state=not-found --state=failed

  UNIT                           LOAD      ACTIVE   SUB  DESCRIPTION                   
 tmp.mount                      not-found inactive dead tmp.mount                     
 auditd.service                 not-found inactive dead auditd.service                
 console-screen.service         not-found inactive dead console-screen.service        
 festival.service               not-found inactive dead festival.service              
 kbd.service                    not-found inactive dead kbd.service                   
 live-tools.service             masked    inactive dead live-tools.service            
 plymouth-quit-wait.service     not-found inactive dead plymouth-quit-wait.service    
 plymouth-quit.service          not-found inactive dead plymouth-quit.service         
 plymouth-start.service         not-found inactive dead plymouth-start.service        
 systemd-sysusers.service       not-found inactive dead systemd-sysusers.service      
 systemd-update-done.service    not-found inactive dead systemd-update-done.service   
 systemd-vconsole-setup.service not-found inactive dead systemd-vconsole-setup.service
 syslog.target                  not-found inactive dead syslog.target                 

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

এবং:

# systemd-cgls -u user-132.slice

Unit user-132.slice (/user.slice/user-132.slice):
├─user@132.service
 ├─pulseaudio.service
  └─739 /usr/bin/pulseaudio --daemonize=no
 ├─at-spi-dbus-bus.service
  ├─704 /usr/lib/at-spi2-core/at-spi-bus-launcher
  ├─709 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
  └─712 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
 ├─dbus.service
  └─694 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
 └─init.scope
   ├─597 /lib/systemd/systemd --user
   └─600 (sd-pam)
└─session-c1.scope
  ├─577 gdm-session-worker [pam/gdm-launch-environment]
  ├─613 /usr/lib/gdm3/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
  ├─618 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/132/gdm/Xauthority -background none -noreset -keeptty -verbose 3
  ├─697 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
  ├─721 /usr/bin/gnome-shell
  └─752 /usr/lib/gnome-settings-daemon/gnome-settings-daemon

2
এই উত্তরটি অন্তত আমাদের ব্যক্তিগত মেশিনগুলিতে কী কী সমস্যা সমাধান করতে পারে তার (বহু সম্ভাবনার মধ্যে) কীভাবে তা খুঁজে বের করার জন্য কিছু তথ্য দিন। তবুও অন্য সমস্যাটি হ'ল এক poweroffবা shutdownআমরা আসল অপরাধীকে দেখার জন্য লগইন করতে পারি না । systemd- কে cgls থেকে আউটপুট লগ করতে হবে যখন এই সমস্যা দেখা দেয়। আপাতত আমরা যেটা করতে পারি তা হ'ল আউটপুটটি সংরক্ষণ করা systemd-cglsএবং যদি / যখন হ্যাং আবার ঘটে তখন এর সাথে পরামর্শ করুন।
duanev

2

যেহেতু এটি বন্ধুত্বপূর্ণ সার্চ ইঞ্জিনের প্রথম ফলাফলগুলির মধ্যে একটি, তাই আমি এখানে আমার সমাধানটি যুক্ত করব: আমি জিনোম ডেস্কটপ দিয়ে আর্চ লিনাক্স ব্যবহার করছি; বর্তমান কার্নেল আজ হিসাবে: 4.16।

A stop job is running for Session c2 of user ... (1min 30s)যখনই Remote Loginসক্রিয় হয়েছিল তখন আমি বার্তাটি পেয়েছি Settings > Sharing, এবং Sharingসক্রিয় হয়েছিল।

যখনই আমি এটিকে অক্ষম করতাম, জিনোম শাটডাউন বোতামটি ব্যবহার করে আমার কম্পিউটারটি দুর্দান্তভাবে বন্ধ হয়ে যাবে।

যেহেতু "রিমোট লগইন" এসএসএইচ ব্যতীত অন্য কিছু নয়, আমি ধরে নিয়েছি যে নোট 2 বিবিটের উত্তরটিও কাজ করবে, কারণ নেটওয়ার্কম্যানেজার অক্ষম করা সম্ভবত এসএসএইচটিকে অক্ষম করে দেবে।


1

কখনও কখনও এটি একটি অ্যাপ্লিকেশন দ্বারা সৃষ্ট হতে পারে। এটি শুরু হওয়ার ঠিক আগে ঘটে যাওয়া পরিবর্তনগুলি মনে রাখার কারণটি চিহ্নিত করতে সহায়ক হতে পারে। skypeforlinux-stable-binআর্ক লিনাক্সে ইনস্টল করার পরে আমারও একই সমস্যা ছিল । শাট ডাউন করার আগে অ্যাপ্লিকেশনটি বন্ধ করে দেওয়া সমস্যার সমাধান করেছে (বন্ধ করার আগে এটি স্বয়ংক্রিয়ভাবে সম্পন্ন করার জন্য আমি একটি স্ক্রিপ্ট লিখেছিলাম)।


0

আমার দীর্ঘদিন ধরে এই সমস্যাটি ছিল, তাই আমি ভেবেছিলাম আমার সমাধানটি ভাগ করব।

সমস্যাটি হ'ল গুগল ক্রোম পটভূমিতে চলছে এবং কম্পিউটারটি বন্ধ করার সময় বন্ধ হয় না। সুতরাং সেরা সমাধানটি সেই বৈশিষ্ট্যটি বন্ধ করে দেওয়া।

  1. গুগল ক্রোমের সেটিংসে যান।
  2. "অ্যাডভান্সড" এ ক্লিক করুন।
  3. "সিস্টেম" এ যান।
  4. "গুগল ক্রোম বন্ধ হয়ে গেলে পটভূমি অ্যাপ্লিকেশনগুলি চালিয়ে যাওয়া চালিয়ে যান" অক্ষম করুন।

এখানে চিত্র বর্ণনা লিখুন

এটি আমার জন্য এটি সমাধান করেছে। আশা করি এটা সাহায্য করবে.

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.