Bug 636752

Summary: it is easy too crash systemd on startup
Product: [Fedora] Fedora Reporter: Tomasz Torcz <tomek>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-08 00:43:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
f15-systemd-crash.png
none
636752-backtrace1.txt none

Description Tomasz Torcz 2010-09-23 07:25:50 UTC 
Description of problem:
Short version:
mkdir /etc/systemd/system/smolt.service.wants
touch /etc/systemd/system/smolt.service.wants/var-cache-yum.mount

Reboot, see systemd crash just after setting hostname (screenshot attached).


Long version:
I was playing with systemd.  In /etc/fstab I have defined /var/cache/yum mount, which during normal work is interpreted by systemd. I have also /etc/init.d/smolt, which also gets interpreted into smolt.service (smolt has nothing to do with cache/yum mount, I picked it randomly).
I tried to have this fstab-intepreted mountpoint to be mounted on boot. So I created smolt.service.wants (as smolt is started during bootup). Inside I created empty _file_ (var-cache-yum.mount is interpreted, there's no file to symlink to) with the name same as autointepreted mountpoint. 
At this point I cannot boot. Neither normally, nor to emergency.target or rescue.target.
Booting with init=/bin/bash and removing /etc/systemd/system/smolt.service.wants/ direcotry allow for subsequent boot to finish.



Version-Release number of selected component (if applicable):
systemd-10-4.fc15.x86_64

How reproducible:
Always.

Expected results:
systemd should be more resilient for incorrect configuration.
Comment 1 Tomasz Torcz 2010-09-23 07:42:31 UTC 
Created attachment 449139 [details]
f15-systemd-crash.png
Comment 2 Lennart Poettering 2010-09-23 07:50:13 UTC 
Could you get me the backtrace for this?

It should suffice reproducing this when having "rw" on the kernel command line. This should then create a core dump in /
Comment 3 Tomasz Torcz 2010-09-23 08:19:28 UTC 
Create core has 0 length and lacks PID extension.  What else can I try?

-rw-------.   1 root root    0 09-23 10:09 core
Comment 4 Tomasz Torcz 2010-09-23 17:18:14 UTC 
Created attachment 449266 [details]
636752-backtrace1.txt

[Thread debugging using libthread_db enabled]
0x00007f3915389ca0 in __pause_nocancel () at ../sysdeps/unix/syscall-template.S:82
82      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
#0  0x00007f3915389ca0 in __pause_nocancel () at ../sysdeps/unix/syscall-template.S:82
No locals.
#1  0x0000000000409145 in freeze (sig=<value optimized out>) at src/main.c:75
No locals.
#2  crash (sig=<value optimized out>) at src/main.c:170
        __func__ = "crash"
        __PRETTY_FUNCTION__ = "crash"
#3  <signal handler called>
No symbol table info available.
#4  __strcmp_sse2 () at ../sysdeps/x86_64/strcmp.S:214
No locals.
#5  0x00000000004594e3 in fstype_is_network (fstype=0x0) at src/util.c:1788
        table = {0x48e9ee "cifs", 0x48e9f3 "smbfs", 0x48e9f9 "ncpfs", 0x48e9ff "nfs", 0x48ea03 "nfs4", 0x48ea08 "gfs", 0x48ea0c "gfs2"}
        i = <value optimized out>
#6  0x00000000004236f6 in mount_add_target_links (u=0x17eb050) at src/mount.c:252
        noauto = false
        handle = true
        target = <value optimized out>
        p = <value optimized out>
        tu = <value optimized out>
        r = <value optimized out>
        automount = false
        user = false
#7  mount_load (u=0x17eb050) at src/mount.c:411
        what = 0x0
        m = 0x17eb050
        r = 0
        __PRETTY_FUNCTION__ = "mount_load"
#8  0x00000000004601da in unit_load (u=0x17eb050) at src/unit.c:788
        r = <value optimized out>
        __PRETTY_FUNCTION__ = "unit_load"
        __func__ = "unit_load"
#9  0x000000000040f28e in manager_dispatch_load_queue (m=0x1719260) at src/manager.c:1608
        meta = <value optimized out>
        n = <value optimized out>
        __PRETTY_FUNCTION__ = "manager_dispatch_load_queue"
#10 0x000000000041db17 in service_enumerate (m=0x1719260) at src/service.c:2763
        p = 0x15d4398
        i = <value optimized out>
        d = <value optimized out>
        path = 0x15d2310 "/etc/rc.d/rc6.d"
        fpath = 0x15f1db0 "/etc/rc.d/rc6.d/K88rsyslog"
        name = <value optimized out>
        runlevel_services = {0x172b0a0, 0x17369f0, 0x17376c0, 0x1737af0, 0x1737f20, 0x1739020, 0x173a590}
        shutdown_services = 0x1738350
        service = 0x1736150
        j = <value optimized out>
        r = <value optimized out>
        __PRETTY_FUNCTION__ = "service_enumerate"
        __func__ = "service_enumerate"
#11 0x000000000040f381 in manager_enumerate (m=0x1719260) at src/manager.c:473
        r = <value optimized out>
        q = <value optimized out>
        c = <value optimized out>
        __PRETTY_FUNCTION__ = "manager_enumerate"
#12 0x000000000041170a in manager_startup (m=0x1719260, serialization=0x0, fds=0x0) at src/manager.c:574
        r = <value optimized out>
        q = <value optimized out>
        __PRETTY_FUNCTION__ = "manager_startup"
#13 0x000000000040a0b7 in main (argc=1, argv=0x7fff77d1e4f8) at src/main.c:1021
        m = 0x1719260
        r = <value optimized out>
        retval = 1
        fds = 0x0
        reexecute = false
        __func__ = "main"
        __PRETTY_FUNCTION__ = "main"
A debugging session is active.

        Inferior 1 [process 1] will be detached.
Comment 5 Tomasz Torcz 2010-09-25 16:09:46 UTC 
I think I tracde this down.  Man page of systemd.mount says that Type= is optional and systemd allows units without type defined. Bu then it crashes in fstype_is_network(), because fstype is NULL.
Comment 6 Lennart Poettering 2010-10-08 00:43:29 UTC 
Fixed upstream.