[systemd-devel] troubleshooting different behaviour of systemd between f16 and f18

[Thierry Parmentelat]

Hi Lennart

Thanks for the feedback; I didn't know that, so it might come in handy in understanding the problem

However, I'm puzzled because it looks like there's no attempt at all to launch pl_sysinit

The reason I came to believe that is with what I can see specifically on f18 where the init sequence hangs, is
...
[    6.457869] systemd[1]: Starting pl_boot service...
         Starting pl_boot service...
[    6.472586] systemd-journald[66]: Received SIGUSR1
[  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
[    6.479961] systemd[1]: Started Trigger Flushing of Journal to Persistent Storage.
[  900.000452] systemd[1]: Starting Cleanup of Temporary Directories...
...

while the f16 log at around the same stage reads

...
Started Recreate Volatile Files and Directories                        [  OK  ]
Started IPv4 firewall with iptables                                    [  OK  ]
Started IPv6 firewall with ip6tables                                   [  OK  ]
Starting pl_boot service...                                                    
[    7.106328] pl_sysinit[259]: PlanetLab BootCD - distro lxc based on f16
[    7.118254] pl_sysinit[259]: 04:34:03 pl_sysinit: bringing system online
[    7.131521] pl_sysinit[259]: 04:34:03 pl_sysinit: mounting file systems
[    7.144839] pl_sysinit[259]: mount: none already mounted or /dev/pts busy
...


Now, another explanation of course is that pl_sysinit does get started but that somehow its output does not show up in this log;
both attempts run with
systemd.log_level=debug systemd.log_target=kmsg


again I'm running sysmted 37 on f16 and systemd 197 on f18

---
Thanks for any advice :) 

-- Thierry


On Feb 13, 2013, at 3:26 AM, Lennart Poettering wrote:

> On Mon, 11.02.13 13:37, Thierry Parmentelat (thierry.parmentelat at inria.fr) wrote:
> 
>> Hi
>> Feel free to redirect me to some other place if needed :)
>> 
>> So, we have a BootCD that is intended for remotely managed machines
>> In a nutshell, we need to redefine the whole init sequence, and what we had on f12 and f14 boxes was essentially a set of 2 init scripts, one for rough system initialization (pl_sysinit), and one for downloading a stage2 python script (pl_boot), in this order of course
>> 
>> ----
>> I'd done the job of adapting to systemd for f16 at the time; my approach had been as simple as it gets (for legacy reasons we're going to have the 2 scripts around anyway, so optimizing all that in a systemd-specific way is not yet in order unfortunately)
>> So in the boot image I had only
>> 
>> * created(replaced?) a symlink 
>> # ls -l /etc/systemd/system/default.target
>> lrwxrwxrwx 1 root root 34 Feb 11 08:12 /etc/systemd/system/default.target -> /etc/systemd/system/pl_boot.target
>> 
>> * and added 2 files
>> ==> /etc/systemd/system/pl_boot.service <==
>> [Unit]
>> Description=pl_boot service
>> 
>> [Service]
>> ExecStart=/etc/init.d/pl_boot
>> ExecStartPre=/etc/init.d/pl_sysinit
>> Type=oneshot
> 
> Is pl_sysinit supposed to leave processes around? This is not allowed anymore.
> 
> Lennart
> 
> -- 
> Lennart Poettering - Red Hat, Inc.