/ 
Ubic-1.32_01
River stage two • 9 direct dependents • 15 total dependents
/ Ubic::Manual::FAQ

NAME

Ubic::Manual::FAQ - frequently asked questions about Ubic

VERSION

version 1.32_01

QUESTIONS

I changed my service's user, and now it fails with "Permission denied" error. Please help!

You have to chown your service files manually. Try this:

find /var/lib/ubic -name '*MY_SERVICE_NAME*' | xargs chown -R MY_NEW_USER

In the future, this one-liner will be reimplemented as "ubic fix-permissions" command. Sorry for the inconvenience.

What is this ubic-guardian process I see in my "ps aux" output?

At early stages of ubic development, there was an idea that usual pidfiles are unsafe: presence of pidfile doesn't guarantee that process is still alive, and presence of process with pid from pidfile in ps doesn't guarantee it either.

So we thought about daemons which hold lock on pifile for a whole lifetime. This way Linux kernel does the job for us and we can be sure that locked pifile guarantees that process is alive. Since ubic is all about separation of programs and damonizing/watchdog/metadata, we needed external process to hold that lock. Hence, ubic-guardian. (BTW, ubic-guardian is not a separate script. It is just a part of Ubic::Daemon code which replaces $0.)

Later, Ubic::Daemon learned to compare process start timestamp. Timestamp and pid together are enough to identify process, so lock is now unnecessary. I think I'll get rid from ubic-guardian process in future releases (transparently from Ubic::Daemon point of view, of course so you shouldn't worry about compatibility).

Maybe the best solution would be to provide alternative Ubic::Service::* modules which would use Net::Daemon::Daemonize, Daemon::Daemonize, MooseX::Daemonize or other daemonization modules from CPAN. Ubic::Daemon works and definitely mature enough for production, but it's Linux-specific (but you can always ignore Ubic::Daemon and describe your own service using Ubic::Service::Common, of course).

What ubic.update service does?

ubic.update service (and ubic-update script) updates portmap - local { port = service-name }> mapping. It makes possible to check service status via ubic.ping using service port instead of its name:

$ wget -q -O - 'http://localhost:12345/status/port/12345'
ok

Resolving of service by port can't be done on-the-fly by ubic.ping, because all service definitions are cached internally by Ubic.pm (Ubic::Multiservice, actually, but you don't have to know the difference), since constant reloading of service definition can cause memory leaks. So ubic.ping instead just loads portmap generated by ubic.update, resolves service name by port, and loads cached service status from another local file.

In other words, if you don't use ubic.ping, you can stop both ubic.update and ubic.ping services.

How is ubic compatible with SysV-style /etc/rcX.d/ symlinks?

It is not. It's recommended that you don't use chkconfig or update-rc.d or similar tools for installing runlevel symlinks at all.

In ubic, desired service status is stored at JSON files at /var/lib/ubic/status/ dir. There is no support for runlevels. After reboot, ubic-watchdog will simply start all your services which were started earlier.

This can be fixed by adding abstraction layer to status storage. If you really need runlevels (or chkconfig compatibility), feel free ask again (or implement this abstraction layer yourself).

Why is it called "ubic", anyway?

It's called after "Ubik" - science fiction novel by Philip K. Dick. I spelled it incorrectly in early releases, because "c" and "k" are indistinguishable in Russian language, and now it's too late to fix this stupid typo (and I'll be very thankful to anyone who'll invent appropriate backronym).

Why is it called after "Ubik"? Well, these two quotes can hint to some suggestions:

"This substance, whose name is derived from the word "ubiquity", has the property of preserving people who are in half-life."
"Ubik is a metaphor for God. Ubik is all-powerful and all-knowing, and Ubik is everywhere."

AUTHOR

Vyacheslav Matyukhin <mmcleric@yandex-team.ru>

COPYRIGHT AND LICENSE

This software is copyright (c) 2011 by Yandex LLC.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.