Summary: | net-analyzer/ntop-5.0.1-r1 installs /etc/cron.monthly/ntop-update-geoip-db which calls /etc/init.d/ntop which is not compatible with systemd | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | Current packages | Assignee: | Gentoo Netmon project <netmon> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | systemd, zerochaos |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Juergen Rose
2013-12-01 21:17:43 UTC
I don't mind systemd compatibility, but I'll definitely need someone fluent with insane to help fix. Install vixie-cron in the meantime? (In reply to Sean McGovern from comment #2) > Install vixie-cron in the meantime? I suppose etc/cron.monthly/ntop-update-geoip-db is executed by vixie-cron. At least vixie-cron is installed. (In reply to Rick Farina (Zero_Chaos) from comment #1) > I don't mind systemd compatibility, but I'll definitely need someone fluent > with insane to help fix. I assume a /usr/lib/systemd/system/ntop.service (similar to /etc/init.d/ntop) should be created. And int /etc/cron.monthly/ntop-update-geoip-db /etc/init.d/ntop --quiet status && /etc/init.d/ntop restart could be replace by: if ps -ef | grep systemd | grep -v grep; then systemctl restart ntop else /etc/init.d/ntop --quiet status && /etc/init.d/ntop restart fi (In reply to Juergen Rose from comment #4) > (In reply to Rick Farina (Zero_Chaos) from comment #1) > > I don't mind systemd compatibility, but I'll definitely need someone fluent > > with insane to help fix. > > I assume a /usr/lib/systemd/system/ntop.service (similar to > /etc/init.d/ntop) should be created. And int > /etc/cron.monthly/ntop-update-geoip-db > > /etc/init.d/ntop --quiet status && /etc/init.d/ntop restart > > could be replace by: > > if ps -ef | grep systemd | grep -v grep; then Wait, what? I don't know systemd internals that well, but I am absolutely sure there is a better way than screen-scraping ps output with grep (badly) twice. If we're really talking about finding out which RC is being run: 1. [ -d /run/systemd/system ] (it's the method used in systemd libraries), 2. [ ! -e "/run/openrc/softlevel" ] (it's used e.g. in NetworkManager, see bug #489396). But in fact, either way sucks. It's weird to make random cron scripts aware of any random service supervisors. It'd be better if ntop simply was able to find out when the files are updated and automatically reload them. From systemd side, this can be easily handled via a .path unit. (In reply to Michał Górny from comment #6) > If we're really talking about finding out which RC is being run: > > 1. [ -d /run/systemd/system ] (it's the method used in systemd libraries), > > 2. [ ! -e "/run/openrc/softlevel" ] (it's used e.g. in NetworkManager, see > bug #489396). > > > But in fact, either way sucks. It's weird to make random cron scripts aware > of any random service supervisors. It'd be better if ntop simply was able to > find out when the files are updated and automatically reload them. > > From systemd side, this can be easily handled via a .path unit. And that's why I included systemd on this. :-) Would you be kind enough to handle this ".path unit" and I'll update the script to not reload the service if openrc isn't in control? That should be a pretty good solution... I don't mind trying, however... shouldn't ntop get a systemd unit first? I kinda don't see one in the ebuild, or am I missing something? (In reply to Michał Górny from comment #8) > I don't mind trying, however... shouldn't ntop get a systemd unit first? I > kinda don't see one in the ebuild, or am I missing something? I don't know anything about systemd, and as such I can't support it. The best I can do it accept what I'm given, and I'm happy to do that. (In reply to Rick Farina (Zero_Chaos) from comment #9) > (In reply to Michał Górny from comment #8) > > I don't mind trying, however... shouldn't ntop get a systemd unit first? I > > kinda don't see one in the ebuild, or am I missing something? > > I don't know anything about systemd, and as such I can't support it. The > best I can do it accept what I'm given, and I'm happy to do that. I expect to have a bit of time for this in some days... but you can start to work on the updated cron file (I guess it will simply run "systemctl start ntop" when needed) in parallel, then we can attach the file here, I will do the same with unit file and we can commit both at the same time Regarding how to pass options to ntop, I like to fedora approach for this concrete case: https://wiki.gentoo.org/wiki/Project:Systemd/Ebuild_policy#Unit_file_guidelines They rely on the ability of ntop to parse a config file like "ntop @/etc/ntop.conf" for getting the parameters like: http://pkgs.fedoraproject.org/cgit/ntop.git/tree/ntop.conf Maybe this could be reused for init.d file also What does maintainer think? removed from the tree |