[X] My Assistant

I bet you're running the H@H process as a different user than you think you are.

When you start H@H you must be the user that owns the files.

I bet you're running the H@H process as a different user than you think you are.

When you start H@H you must be the user that owns the files.

The process is started by the init.d script (ie by the system at startup), and in there the user is defined as the same user as the file owner.
I use the script provided on the very helpful wiki page http://ehwiki.org/wiki/Installing_H@H_on_Debian
edited for my system.
The relevant section is as follows.

CODE

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="Hentai@Home service"
NAME=hentaiathome
DAEMON=/usr/bin/java
USER=hath
DIR=/home/hath/
DAEMON_ARGS="-jar HentaiAtHome.jar"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

Is there any reason why files in the /home/hath folder wouldn't be owned by user hath?
Is there any reason why the service would be started as any user other than hath, given what's above?
Is there any way of checking what user it's running under?

I genuinely don't know. What's weird is my Quality and Trust are climbing, so I don't want to rock the boat by changeling settings, but at the same time it seems that files aren't being downloaded correctly and I can't imagine that doing it's job as a server any good, so I'd like to have it running flawlessly if possible.

EDIT: I'm not sure why, but if I'm reading this right, it seems all the directories are owned by root, I can see this causing a problem so I've changed the ownership. The questions kinda still stand though, why would they be owned by root, and if I change the ownership to user hath will it remain so?

EDIT2: Everything was owned by root. I've changed it all (at least I hope it's all) to hath, but I still can't see why newly downloaded files in the tmp folder would be owned by root. If things aren't being run why who they should be, I could be encountering more problems left and right.

This post has been edited by Demon Z: Sep 8 2015, 18:26

Is there any reason why files in the /home/hath folder wouldn't be owned by user hath?

yes, there might be. Which would be an issue for H@H. But there is nothing preventing files under /home/hath having any strange ownership.

Is there any reason why the service would be started as any user other than hath, given what's above?

Yes, but unlikely. Debian init.d scripts are pretty good and if the scripts says USER=hath it will do it properly.

Is there any way of checking what user it's running under?

Yes, and it is a wise point to do so. Check under which user H@ is running with

CODE

ps -afe | grep Hentai

all the directories are owned by root, I can see this causing a problem so I've changed the ownership. The questions kinda still stand though, why would they be owned by root, and if I change the ownership to user hath will it remain so?

Certainly an issue. And had we not looked at trying to find the user that the process is running under that's what i would be suggesting. But just in case, when you restart H@H you do it with

CODE

service hentaiathome restart

right? (and that must be run as root)

will it remain so?

Another possibility is that you're restarting H@H as root (which you must because it runs as a service) and then looking into the files from the same terminal. Open two terminals: one as root just to execute "service hentaiathome restart" and another terminal as user hath which you will use to read the logs, etc.

PS: to find all files and directories owned by root you can do:

CODE

find /home.hath -user root

Thank you for your most comprehensive response!

yes, there might be. Which would be an issue for H@H. But there is nothing preventing files under /home/hath having any strange ownership....

...Yes, but unlikely. Debian init.d scripts are pretty good and if the scripts says USER=hath it will do it properly...

...Yes, and it is a wise point to do so. Check under which user H@ is running with

CODE

ps -afe | grep Hentai

Very handy. my little book of linux showed me the ps function, but I'm still learning the options to narrow down the searches. Looking at the massive list of all the processes and your handy little search tool both confirmed the same, it's running as user hath.

CODE

hath     15099     1  2 15:11 ?        00:05:45 /usr/bin/java -jar HentaiAtHome.jar

Certainly an issue. And had we not looked at trying to find the user that the process is running under that's what i would be suggesting. But just in case, when you restart H@H you do it with

CODE

service hentaiathome restart

right? (and that must be run as root)

Indeed! That is how it's done, or directly from "$ sudo /etc/iniit.d/hentaiathome restart", with liberal use of sudo. I log in as my admin account and sudo from there. User hath has no such permissions and I try to administer everything from a single admin user. Maybe that's where I mucked up, misapplying permissions with sudo without specifying a user?

Another possibility is that you're restarting H@H as root (which you must because it runs as a service) and then looking into the files from the same terminal. Open two terminals: one as root just to execute "service hentaiathome restart" and another terminal as user hath which you will use to read the logs, etc.

Humm, a possibility. As previously mentioned I use an admin user, so to look into the /home/hath directory i need to sudo. Interestingly nothing was marked as owned by my admin account, again, possibly misapplied sudo. Hilariously though I don't read the logs from within the (SSH) terminal. I open them in notepad on my local (windows) machine by accessing them over samba (logged in as user hath, as far as I can tell). Do you think accessing files this way may contribute to weirdness?

PS: to find all files and directories owned by root you can do:

CODE

find /home.hath -user root

Fantastic advice, everything in the cache folders was still owned by root. I'd been using chown and liberal uses of ./*/*/* from within the home/hath directory but it clearly hadn't penetrated that far.

So, assuming that having all the ownership set correctly has solved a few problems, is it worth restarting the server/service? Though this whole weirdness my trust and quality have been (slowly) going up, so I've been doing all this while leaving it live. No new files have been served though, and the single gallery I tried using the H@H downloader with hasnt happened (permissions error to do with that right at the top of the error log.)
Does a restart sound wise? I'm paranoid it'll all go to crock again.

This post has been edited by Demon Z: Sep 8 2015, 19:36

Hilariously though I don't read the logs from within the (SSH) terminal. I open them in notepad on my local (windows) machine by accessing them over samba (logged in as user hath, as far as I can tell). Do you think accessing files this way may contribute to weirdness?

Unlikely, samba is pretty well tested for such cases. Although it is easy to test: create a new file in the data directory from the notepad on windows, and go there in the terminal an check if it is owned by hath. (a new file is a better test than an edit, as edits done by root do not change ownership)

So, assuming that having all the ownership set correctly has solved a few problems, is it worth restarting the server/service? Though this whole weirdness my trust and quality have been (slowly) going up, so I've been doing all this while leaving it live. No new files have been served though, and the single gallery I tried using the H@H downloader with hasnt happened (permissions error to do with that right at the top of the error log.)
Does a restart sound wise? I'm paranoid it'll all go to crock again.

I'd restart it, for three reasons:

1. I suspect it is a new client (less than a week?). Tenboro does have an algorithm that prioritises new H@H clients for cache building, therefore one hour of downtime will not impact much.

2. We do not know the code on the server side, and there might be some safety guards that will not allow the client to get the same cache file if it failed before (just a guess but seems possible). Such safeguards would be dropped on restart.

3. You will be dead scared of restarting that machine in the future. And that is very bad. If something goes wrong months from now you will not remember all the things you did today and might end in a horrible configuration nightmare. If something goes wrong today just after the restart it will be easier to fix.

Thank you again for being so patient with me.
I've done the reboot, and from the H@H control panel it's showing as online and well, and my new error log is all shiny and short of permissions errors.
It does have this new one though, which I'm not concerned about as such, as it seems everything is working regardless, but I'm interested in all the little weirdities as they crop up.

CODE

*********************************************************
2015-09-08T18:55:45Z Logging started
2015-09-08T18:55:45Z [WARN] Unknown host rpc.hentaiathome.net, aborting..
2015-09-08T18:55:45Z [WARN] Exhaused retries or aborted getting http://rpc.hentaiathome.net/clientapi.php?clientbuild=96&act=server_stat
2015-09-08T18:55:45Z [ERROR] {org.hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:284)} Critical Error: Failed to get initial stat from server.

Sounds like possibly something which was mentioned, it had so many issues with a particular file or similar that the server has shut it out temporarily, maybe?
As I said though, seems to be working ok, that's literally the only error and it seems to be carrying on as intended anyway.

3. You will be dead scared of restarting that machine in the future. And that is very bad. If something goes wrong months from now you will not remember all the things you did today and might end in a horrible configuration nightmare. If something goes wrong today just after the restart it will be easier to fix.

I'm hoping months down the line I'm comfortable enough with Debian by then to be able to handle issues better, but I get your point. Remembering things is hard enough one day to the next without going months and months into the past.

Unlikely, samba is pretty well tested for such cases. Although it is easy to test:...

Test came out ok. Samba creating files owned by the correct people.

Hurrah for becoming a contributing member of society!
And thank you once more and again Blue Penguin, you're a gentlemen and sir for putting up with silly old me.

EDIT: Not a few minuets after making this post it changed from 'online' to 'timeout'. So.....restarted the service, no errors at all....online and ok....for now. Trust and Quality is dropping, but while there's no errors to fix I'm just going to wait it out for awhile before panicking. After reading up it's probably because I didn't shut the service down before rebooting the machine, leading to a bad shutdown. My bad. If everything's fine I'll sort itself out. Welp, while It keeps looking ok I'll not trouble you again. Love and peace ya'll.

This post has been edited by Demon Z: Sep 8 2015, 21:27

Good! That first thing must just have been a DNS hickhup on the provider of your box. Nothing to worry about

Happy hacking on your Debian.

new one

but i don't know what it is

I am using ubuntu, not debian one.

until now I only use tmux/screen. not using init.d script.

everything went smooth.

Thx (IMG:[invalid] style_emoticons/default/tongue.gif) (IMG:[invalid] style_emoticons/default/tongue.gif) (IMG:[invalid] style_emoticons/default/tongue.gif)

I wonder, is it even possible to achieve more than 16MB/s max speed using the vanilla client? I tried, but I seemed to be hard limited on this number, even though the connection was much faster.

The client also didn't exactly got above 8.5k trust, average even below 8k.

After a simple refactoring of the outgoing netcode (sorry^^), it scores now at ~31MB/s in the speed test which is about the average connection speed, and quality is also climbing quickly. Memory usage didn't change much since that's mostly attributed to the SQLite database, but CPU usage also went down.

That makes me wonder: The few clients which are actually capable of reaching 25 Hath / day, they are not actually vanilla clients, are they? It appears to be about impossible.


Oh, by the way. There is a missing semaphore on log rotation. During log rotation, threads can get killed by an uncaught IOException. Happened so far at every single log rotation for me.

I assume that the 25h/d ones are top-notch seedboxes in Asia and Europe with 100 MB pipes. Not sure if the clients are modded though, this is the first time I've ever read a complaint about it.

I assume that the 25h/d ones are top-notch seedboxes in Asia and Europe with 100 MB pipes. Not sure if the clients are modded though, this is the first time I've ever read a complaint about it.

is it possible to reach 25 h/day with 'murica server ?

murica servers is cheaper. but not many visitors from murica. seems they prefer ben10 porn.

is it possible to reach 25 h/day with 'murica server ?

murica servers is cheaper. but not many visitors from murica. seems they prefer ben10 porn.

There are several visitors from US but also tons of H@H too.

I assume that the 25h/d ones are top-notch seedboxes in Asia and Europe with 100 MB pipes.

That's the same class of server I'm referring to.

And yes, I'm pretty sure now. After fixing a few more mistakes in the netcode, I'm now stable above 9k quality and rising, and requests are now successfully peaking at 10MB/s and more. (Yes, that's clients with more than 100Mbit/s downstream...)

Don't get me wrong. The H@H client is working perfectly fine for home connections and alike, where throttling is desired and required, and you are mostly limited by your own servers upstream and not the clients downstream. It's not doing it in the most efficient or smart way, but it is doing its job.

It's just not scaling very well above 50-100Mbit/s upstream due to some conceptual flaws in the throttling system (even when turned off!), some unnecessary copies between buffers, and a few violations against the Java API when setting up the socket. (Hint: Socket.setReceiveBufferSize doesn't work at all when called too late.)

And in the end, fully unthrottled connections profit both the server and the clients, as neither has to wait as long until the connection is finished.

That's the same class of server I'm referring to.

And yes, I'm pretty sure now. After fixing a few more mistakes in the netcode, I'm now stable above 9k quality and rising, and requests are now successfully peaking at 10MB/s and more. (Yes, that's clients with more than 100Mbit/s downstream...)

Don't get me wrong. The H@H client is working perfectly fine for home connections and alike, where throttling is desired and required, and you are mostly limited by your own servers upstream and not the clients downstream. It's not doing it in the most efficient or smart way, but it is doing its job.

It's just not scaling very well above 50-100Mbit/s upstream due to some conceptual flaws in the throttling system (even when turned off!), some unnecessary copies between buffers, and a few violations against the Java API when setting up the socket. (Hint: Socket.setReceiveBufferSize doesn't work at all when called too late.)

And in the end, fully unthrottled connections profit both the server and the clients, as neither has to wait as long until the connection is finished.

The vanilla H@H client works perfectly well for maxing hath generation on big pipes with the loads that you're likely going to see. If you aren't getting good performance (maxed hath, quality, and trust), I would take a careful look at your network quality and disk IO to start with.

This is not to say that you can't write a client that will perform significantly better than the vanilla H@H client-- because it's not terribly difficult to-- but there's no real need for it at the moment. (I played around with a version that could handle several orders of magnitude more concurrent connections in tests, but never bothered to maintain it.)

anyone know cheap VPS that have huge disk and unmetered monthly transfer ?

my murica vps just suspended. exceed the monthly data transfer quota :/

Hey guys. I started my first H@H client 6 hours ago, so this may be a stupid question, but I don't know what to do.
It started with no problems, gained 600 trust and 2200 quality in 5 hour period. Then I added 98 galleries to H@H download. Client downloaded 3 galleries in 30 minutes, everything worked fine. And then my trust suddenly dropped to -100 in about 5 minutes. Quality dropped to 1489. It was like this for about 40 minutes. Now, after 40 minutes my trust is slowly increasing [-86 atm], but quality still drops [~1400 atm].
So what happened? My connection is perfectly fine, no drops, no client shutdowns, no cache clearing. It just happened randomly, without my interaction.
I would like to avoid anything like that in the future, so please give me some hints about resolving this problem.

Oh and one more question. What does this mean? "Could not grab token list - most likely the client has not been qualified yet. Will retry in a few minutes."

This post has been edited by cichy133: Sep 20 2015, 22:06

anyone know cheap VPS that have huge disk and unmetered monthly transfer ?

my murica vps just suspended. exceed the monthly data transfer quota :/

ovh, delimiter, etc.

It started with no problems, gained 600 trust and 2200 quality in 5 hour period. Then I added 98 galleries to H@H download. Client downloaded 3 galleries in 30 minutes, everything worked fine. And then my trust suddenly dropped to -100 in about 5 minutes. Quality dropped to 1489. It was like this for about 40 minutes. Now, after 40 minutes my trust is slowly increasing [-86 atm], but quality still drops [~1400 atm].
So what happened? My connection is perfectly fine, no drops, no client shutdowns, no cache clearing. It just happened randomly, without my interaction.
I would like to avoid anything like that in the future, so please give me some hints about resolving this problem.

Probably something happened on the network even if you weren't aware of it. Eg, 10% packet loss was enough to cause Trust and Quality to nosedive for one of my clients recently.

Oh and one more question. What does this mean? "Could not grab token list - most likely the client has not been qualified yet. Will retry in a few minutes."

"Just wait". It's probably related to the above, and will recover eventually / once the above gets resolved.

I'm having a strange problem.

When I start H@H, it simply says this:


2015-10-07T10:21:45Z [info] Started logging to data/log_out
2015-10-07T10:21:45Z [info] Started logging to data/log_err
2015-10-07T10:21:45Z [info] Hentai@Home 1.2.5 starting up
2015-10-07T10:21:45Z [info]
2015-10-07T10:21:45Z [info] Copyright © 2008-2014, E-Hentai.org - all rights reserved.
2015-10-07T10:21:45Z [info] This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL v3 license.
2015-10-07T10:21:45Z [info]
2015-10-07T10:21:45Z [info] Loaded login settings from client_login
2015-10-07T10:21:45Z [info] Connecting to the Hentai@Home Server to register client with ID 2640...
2015-10-07T10:21:45Z [info] Connecting to rpc.hentaiathome.net...
2015-10-07T10:21:45Z [info] /clientapi.php?clientbuild=96&act=server_stat: Retrieving 74 bytes...


and then does nothing afterwards. I tried manually wgetting the request and I am able to retrieve a reply, so I don't see why it wouldn't work like this. Running as root.

This is on a very low-resource machine, but I figured it'd throw an error if there was a memory problem. Not even all RAM is being taken so that shouldn't be an issue. Using jamvm instead of regular java due to the resource stortage(s).

From what I gather, jamVM should support everything java itself does, and the program doesn't really complain about anything. It just doesn't proceed any further.

Any ideas?