A CA must indeed publish CRL regularly, and if the CA is offline, then human intervention is needed. Each CRL has an issuance date (
thisUpdate) and a provisional date of next publication (
nextUpdate) which everybody uses as an end-of-validity date for the CRL. The next CRL must be published before reaching the
nextUpdate date of the current CRL; otherwise, verifiers will begin to reject the certificates.
Common practice is to have an offline root CA which issues relatively long-lived CRL (e.g. one CRL every three months, with a
nextUpdate set to current time + 4 months). That root CA is used to issue only a single certificate, for an intermediate CA, which is online, and does the bulk of certificate issuance (and that intermediate CA publishes CRL much more regularly). The offline root CA is kept as a "last recourse": if the intermediate CA is compromised, then the root can revoke it, so there is a "bad period" to suffer (until the end of validity of the current root CRL, at most), but the root key distribution needs not be redone when the new (intermediate) CA is built and started.
A niftier method is to have a semi-offline root CA: the root CA is linked with the outer world through a physically one-way canal (I have done it with an audio cable: the "line out" jack on the server is inherently one-way, so no risk of intrusion coming up that cable). This allows the root to publish CRL often (e.g. one per week, even one per day) without needing human intervention. Actual revocation would still need physical intervention, so an intermediate CA as described above would still be highly recommended.
Note that an offline or semi-offline CA cannot synchronize itself with network time sources, so the root CA clock may drift. Since the CRL have a validity period, this requires some supervision (you can tolerate a drift of a few minutes, so this is no hardship, but you'd better keep an eye on it anyway).