|
I've added logging to the dm start sections of smxi/sgfxi, if you can run this again (smxi, then use smxi to start dm) and then post the last roughly 20 lines of smxi log that will show me where systemd is actually leaving the process.
As I noted, my kdm running systemd setup upgraded fully as of a few days ago had no x restart issue, so there's something else going on with the specifics here I suspect, I just have to find out where. Back to top |
|||||
|
I haven't shut down my PC since the last smxi run . . . and it restarted OK as follows :
:: Code :: Function: post_upgrade_options - MASTER: End
Function: print_completed - Utility: Start Args: noquit Function: print_completed - Utility: End Function: start_stop_default_dm - Utility: Start Args: full start Function: get_default_display_manager - Utility: Start defaultDM: lightdm Function: get_default_display_manager - Utility: End dmanCommand: systemctl start lightdm.service nohup: ignoring input and appending output to 'nohup.out' Reached post dmancommand: nohup systemctl start lightdm.service 2>>/var/log/smxi.log && success='true' Kill login PID for dm start: 1206 I then shutdown the PC, ran smxi and got to the login screen. The log output for the fail is : :: Code :: Function: post_upgrade_options - MASTER: End
Function: print_completed - Utility: Start Args: noquit Function: print_completed - Utility: End Function: start_stop_default_dm - Utility: Start Args: full start Function: get_default_display_manager - Utility: Start defaultDM: lightdm Function: get_default_display_manager - Utility: End dmanCommand: systemctl start lightdm.service nohup: ignoring input and appending output to 'nohup.out' Reached post dmancommand: nohup systemctl start lightdm.service 2>>/var/log/smxi.log && success='true' Kill login PID for dm start: 1237 The former started, the latter didn't! Back to top |
|||||
|
There is clearly a missing piece here, since the same exact sequence of commands starts and does not start your desktop from smxi.
It looks like when systemd boots the system, something, unknown, happens, but when you've issued some commands to lightdm/systemd from the desktop, like starting it, stopping it, something else, also unknown, happens. There's a faint possibility that the nohup part makes something in systemd confused, or lightdm, probably lightdm is my guess. Beyond this I can't say, there is no data to debug that I can see, particularly not if the same command works and does not work, that sounds to me like a bug, or a set of circumstances that triggers an unknown reaction in an unknown combination of things like systemd+lightdm. I haven't gotten any reports from sgfxi, which uses the same logic, of failing to start desktops, though this isn't saying much since bug reports have tapered off a lot. Back to top |
|||||
|
The only strange thing is if I stop lightdm.service manually it takes about 3-4 seconds, whereas smxi says it's stopped instantly. Is it not shutting down?
Back to top |
|||||
|
If lightdm is actually not really shutting down, that explains almost all the behavior.
Check, leave desktop, start smxi, agree to shutdown desktop, then: ctrl alt f2, login, and do: ps aux | grep lightdm ignore the grep lightdm line, is it running? If it's running, that's the cause. I've seen this issue before and actually added more monitoring and checks into sgfxi/smxi to handle it, that was the cause of the 'have to run smxi/sgfxi twice to install video drivers' issue for example. Back to top |
|||||
|
I wasn't sure what to expect but when I type
:: Code :: ps aux | grep lightdmI get : :: Code :: root 4018 0.0 0.0 12720 2088 tty2 s+ 20:26 grep lightdmThe desktop will then start with start lightdm.service Back to top |
|||||
|
that means the lightdm process was killed by smxi/sgfxi, so that's not the problem.
I'll see if I can think of something else as a test. It certainly does appear that for some reason systemd is not actually starting the lightdm process even though it claims it did. I think errors are logged so there's nothing to capture but I'll double check. thanks for your patience, this isn't an obvious bug or failure. Back to top |
|||||
|
Not sure if this is a bug but the first time smxi has exited with an error. Last section of smxi log reads :
:: Code :: unction: check_kernel - MASTER: Start
Function: sm_pref_tester: smPref: meta-package-selection; $2: equal; value: Function: test_kernel_strings - Utility: Start Args: 4.0.0-towo.1-siduction-amd64 set-ke value: true Function: test_kernel_strings - Utility: End Error line (written down) is as follows : :: Code :: /usr/local/bin/sm-lib-kernel: line 103: 80 - : syntax error: operand expected (error token is "- ")Back to top |
|||||
|
I need to see the full log, something is failing when both kernels are 4.x I believe, I tested this this morning with a 3.19 and the 4.0 towol in smxi and it all worked fine, so clearly something is slightly off in the logic when it's 4.0 for both new and current version.
Back to top |
|||||
|
Log pasted at
jpst.it/ys3w :: Code :: inxi -v3
System: Host: siduction Kernel: 4.0.0-towo.1-siduction-amd64 x86_64 (64 bit gcc: 4.9.2) Desktop: KDE 4.14.2 (Qt 4.8.6) Distro: siduction 14.1.0 Indian Summer - kde - (201411230337) Machine: Mobo: Gigabyte model: Z97X-UD5H v: x.x Bios: American Megatrends v: F7 date: 05/30/2014 CPU: Quad core Intel Core i7-4790 (-HT-MCP-) cache: 8192 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 28808 clock speeds: max: 4000 MHz 1: 4000 MHz 2: 3990 MHz 3: 3921 MHz 4: 3997 MHz 5: 3708 MHz 6: 3964 MHz 7: 3999 MHz 8: 3993 MHz Graphics: Card: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0 Display Server: X.Org 1.16.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1920x1080@60.00hz GLX Renderer: Mesa DRI Intel Haswell Desktop GLX Version: 3.0 Mesa 10.4.2 Direct Rendering: Yes Network: Card-1: Intel Ethernet Connection I217-V driver: e1000e v: 2.3.2-k port: f080 bus-ID: 00:19.0 IF: eth1 state: up speed: 1000 Mbps duplex: full mac: 74:d4:35:ea:b0:d5 Card-2: Qualcomm Atheros Killer E220x Gigabit Ethernet Controller driver: alx port: e000 bus-ID: 02:00.0 IF: eth0 state: down mac: 74:d4:35:ea:b0:d7 Drives: HDD Total Size: 6513.3GB (31.7% used) ID-1: model: ST2000DM001 ID-2: model: ST2000DM001 ID-3: model: Crucial_CT512MX1 ID-4: model: ST2000DM001 Info: Processes: 232 Uptime: 2:54 Memory: 1418.8/15836.5MB Init: systemd runlevel: 5 Gcc sys: 4.9.2 Client: Shell (bash 4.3.331) inxi: 2.2.18 Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||