@Haakon Meland Eriksen
I have serious problem with openshift, I have one million emails :
"Cron tasks not running on......"
I have serious problem with openshift, I have one million emails :
"Cron tasks not running on......"
show all 63 comments
Hm. Have you changed a file permission?
You are supposed to have a poller. This should be created by the deploy script. Here is the code:
You are supposed to have a poller. This should be created by the deploy script. Here is the code:
####
echo "Check for the poller at .openshift/cron/minutely/poller , if not created - create it"
if [ ! -f ${OPENSHIFT_REPO_DIR}.openshift/cron/minutely/poller ]; then
printf '%s\n' '#!/bin/bash' 'if [ ! -f $OPENSHIFT_DATA_DIR/last_run ]; then' ' touch $OPENSHIFT_DATA_DIR/last_run' 'fi' 'if [[ $(find $OPENSHIFT_DATA_DIR/last_run -mmin +9) ]]; then #run every 10 mins' ' rm -f $OPENSHIFT_DATA_DIR/last_run' ' touch $OPENSHIFT_DATA_DIR/last_run' ' # The command(s) that you want to run every 10 minutes' 'cd /var/lib/openshift/${OPENSHIFT_APP_UUID}/app-root/repo; /opt/rh/php54/root/usr/bin/php include/poller.php' 'fi' >${OPENSHIFT_REPO_DIR}.openshift/cron/minutely/poller
echo "Done creating file .openshift/cron/minutely/poller"
else
echo "The poller already exists"
fi
####
# Set permissions on the poller script to make it executable.
echo "Now chmod 777 -R poller"
chmod -R 777 ${OPENSHIFT_REPO_DIR}.openshift/cron/minutely/poller
echo "chmod done, permissions set to 777 on poller script."
Log into your OpenShift account and check if you have cron on your app. Restart the app. See what happens. Best of luck! 
the problem now is stopping this email spammer activity ( 2 emails for minute ... 
) fuck...Cron... i don't want to lose my email in tutanota.
) fuck...Cron... i don't want to lose my email in tutanota.
No, restart means restart the services - MySQL, Apache, PHP, cron. Saved data will not be lost. You may lose some unsaved data, but probably not. Your $OPENSHIFT_DATA_DIR is unaffected by restart.
giac hellvecio
The poller script is supposed to fire every ten minutes. See above snipped for location. When you do ls -l on it, it should be marked as executable, ie the executable bit is on or set to on.
Unfortunately I do not understand these things, and I do not know how to fix it, I would need a very detailed step by step.
'A routine check indicates the scheduled maintenance tasks on this
website are not running. Please review your "cron" jobs or the
equivalent mechanism on your operating system and ensure these are
running. Please review the INSTALL instructions if you are seeing
this message for the first time. If these maintenance tasks have
been running normally until now, please check to see if anything
may have gone wrong to account for them not running currently.
This check is run approximately every three days.
The error message is 'Cron/Scheduled tasks not running.'.
The last successful execution was 'never'.
'
website are not running. Please review your "cron" jobs or the
equivalent mechanism on your operating system and ensure these are
running. Please review the INSTALL instructions if you are seeing
this message for the first time. If these maintenance tasks have
been running normally until now, please check to see if anything
may have gone wrong to account for them not running currently.
This check is run approximately every three days.
The error message is 'Cron/Scheduled tasks not running.'.
The last successful execution was 'never'.
'
I do not find a way to stop emails from also openshift page, there is nothing about this inside openshift-page after the login
Hm. Change or create a READMEGIAC.md and add to git, commit and push to openshift. This should recreate everything. I will be home tomorrow and have access to a keyboard.
i updated .... i can see that Cron started and etc... after git push...but, nothing, the Cron spammer continue, as 3 emails for minute ....terrible
I had all 'success' after git push, but the problem continue... for now I was able to move these emails in the spam folder, hoping that the tutanota staff is clement.
now I have to go out and do something else.
now I have to go out and do something else.
so, I really don't know what i can do...
the only thing that i can do is kill the app e kill the hub, i don't see any other quick solution
the only thing that i can do is kill the app e kill the hub, i don't see any other quick solution
millions of emails ... is impossible to control this in this moment, i need do/control in this moment 'cause i don't want problem with tutanota email
i tried enter in my app etc.. using rhc , but rhc is so complicated and also super uncomfortable for controlling a site in a server.
and the directorys are so so different between what I have in 'local' here and what I have in 'remote', a nightmare
it sound more openshit than openshift argh.....
it sound more openshit than openshift argh.....
It appears this could happen if the config table crashed. I've patched it so that it won't send out millions of emails if this happens, but the site would still be seriously horked.
Haakon Meland Eriksen
@giac hellvecio - did you manage to do a snapshot or backup of your site before you deleted it?
I have created a new hub and now I have again two hubs in myzot domain.
and respect to the old hub, it worked great.
The problem was with OpenShift in my opinion.
The difference of 2 hubs was that:
in one of two I (we) had made the 'emergency commit' (remember in April?) to solve the problem of the white page, and it was exactly because of this for me OpenShift in recent days has sent millions of emails.
Upon git push I noticed that it met 10 objects, while in the hub (which is still active) he always meets 9 objects.
This made me think that the small difference (basically a small change) has put in a crisis the OpenShift system (and specifically something related to the work of 'Cron'), and as if, finding something different from the original (in terms of 'git' I think), something has started to malfunction and Cron somehow has not been able to manage well the little difference.
In any case, recalling that the hub and channels in it worked well, the problem for me is OpenShift and the management of the thing, you can not have all these problems just because there was an old more little commit inside folders. .. a small difference upset all in OpenShift.
what I do not understand is:
why only now, compared to April, I had trouble with 'cron'?
why cron started and stopped immediately? (If it is true that it stopped I do not know - I just have emails as in the comment)
why OpenShift does not let decide to us simply what notifications such as email it send us?
why a small difference send a blow to everything?
and respect to the old hub, it worked great.
The problem was with OpenShift in my opinion.
The difference of 2 hubs was that:
in one of two I (we) had made the 'emergency commit' (remember in April?) to solve the problem of the white page, and it was exactly because of this for me OpenShift in recent days has sent millions of emails.
Upon git push I noticed that it met 10 objects, while in the hub (which is still active) he always meets 9 objects.
This made me think that the small difference (basically a small change) has put in a crisis the OpenShift system (and specifically something related to the work of 'Cron'), and as if, finding something different from the original (in terms of 'git' I think), something has started to malfunction and Cron somehow has not been able to manage well the little difference.
In any case, recalling that the hub and channels in it worked well, the problem for me is OpenShift and the management of the thing, you can not have all these problems just because there was an old more little commit inside folders. .. a small difference upset all in OpenShift.
what I do not understand is:
why only now, compared to April, I had trouble with 'cron'?
why cron started and stopped immediately? (If it is true that it stopped I do not know - I just have emails as in the comment)
why OpenShift does not let decide to us simply what notifications such as email it send us?
why a small difference send a blow to everything?
I understand your need to stop the emails, but without logs it is lost cause trying to figure out why, unless you kept them? Your hub, was it running DEV or master?
Master, I know that I do not have the logs, but in any case I have given a some trail to understand.
I had notification cron email spammer just from one of the 2 hubs in myzot, exactly that who had change in april.
obviously the small change made at the time brought the issue this week in cron and his notifications, for the rest all hubs are equal in myzot, all worked very well, even until yesterday, despite the cron spam
cron had trouble this week to manage the small difference in the two hubs,
why? I do not know, but unfortunately, although I've tried, I've had urgent need to stop it.
why? I do not know, but unfortunately, although I've tried, I've had urgent need to stop it.
what I have understood:
1 do a small commit (subsequent the original) inside the folders in openshift can lead to a problem like this ( for ex. cron will be crazy)
2 it is very difficult to manage well a site inside OpenShift, the webconsole is completely insufficient, and rhc is complicated, inconvenient, uncomfortable etc ...
1 do a small commit (subsequent the original) inside the folders in openshift can lead to a problem like this ( for ex. cron will be crazy)
2 it is very difficult to manage well a site inside OpenShift, the webconsole is completely insufficient, and rhc is complicated, inconvenient, uncomfortable etc ...
obviously, thanks to your idea, we can try , experiment hubzilla at no cost. 
fantastic, but if you open a serious site/hub for hubzilla, I think absolutely is not the case of using 'OpenShift no cost option'.
fantastic, but if you open a serious site/hub for hubzilla, I think absolutely is not the case of using 'OpenShift no cost option'.
I think with the logs of my old hub you were doing nothing.
My hub has worked well until the last second.
Even after the last 'git push' everything was successful, the cron stopped and then started again, all according to the 'git push' display.
what you need is the log of internal openshift services, the last 48 hours, and maybe you can understand why the loop cron notification email. #loop
My hub has worked well until the last second.
Even after the last 'git push' everything was successful, the cron stopped and then started again, all according to the 'git push' display.
what you need is the log of internal openshift services, the last 48 hours, and maybe you can understand why the loop cron notification email. #loop
http://status.openshift.com/ shows there was an event, but it could be unrelated.
yesterday, when i was doing th new hub, i had some problems,
1 I tried 3 times, in the last it worked (all 3 times I have done things absolutely identical ) , perhaps server overload
2 Now hubzilla asks php 5.5, and there (openshift) still does not exist, in any case you see the warning during installation. But it seems that at the end is working
.
1 I tried 3 times, in the last it worked (all 3 times I have done things absolutely identical ) , perhaps server overload
2 Now hubzilla asks php 5.5, and there (openshift) still does not exist, in any case you see the warning during installation. But it seems that at the end is working
.
I believe cron was working. I think your config table crashed. If you review the block of code where we send the 'cron broken' email, we set a config so that we won't ever send more than one every three days. We also use a config setting to set the last time that cron ran. So the fact that you got all these emails tells me that setting config wasn't working; and that typically only happens if the table crashed. It wasn't a general database failure because we check for that on startup and exit the entire application.
what i saw is : in the first days this week i had some email cron notifcation, but yesterday the cron notification email entered in a loop.
I am doing experiments more than anything else in openshift,
the great thing about hubzilla is the fact that the channels that I created, if I consider them interesting, I can always transport them to another hub
the great thing about hubzilla is the fact that the channels that I created, if I consider them interesting, I can always transport them to another hub
That has nothing to do with openshift.
I had the same problem on my hub (VPS).
The solution was (I believe) change of branch to master:
I had the same problem on my hub (VPS).
The solution was (I believe) change of branch to master:
cd /var/www/hubzilla/
git checkout master
git reset --hard master
git pull
cd addon/
git checkout master
git reset --hard master
git pull
Regardless, it should be possible to test by running OPTIMIZE on the config table, then kill it.
http://stackoverflow.com/questions/5140019/how-to-intentionally-crash-mysql-table
http://serverfault.com/questions/53271/how-can-i-force-a-mysql-table-to-become-corrupted
http://stackoverflow.com/questions/5140019/how-to-intentionally-crash-mysql-table
In MyIsam, run OPTIMIZE TABLE and kill it while it runs. The table will be marked as crashed.
http://serverfault.com/questions/53271/how-can-i-force-a-mysql-table-to-become-corrupted
mysql> repair table Transactions;
^CQuery aborted by Ctrl+C
+-----------------------------------+--------+----------+-----------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------------------------+--------+----------+-----------------------+
| test.Transactions | repair | error | 137 when fixing table |
| test.Transactions | repair | status | Operation failed |
+-----------------------------------+--------+----------+-----------------------+
2 rows in set (17.84 sec)
mysql> select * from Transactions limit 1;
ERROR 144 (HY000): Table './test/Transactions' is marked as crashed and last (automatic?) repair failed
about my problem:
the terrible thing is that they have not provided a simple means, by OpenShift, to temporarily stop sending emails in a way total illogical, if I had means to temporarily stop the email crazy spammer, then it would be more easier to study the problem....
the terrible thing is that they have not provided a simple means, by OpenShift, to temporarily stop sending emails in a way total illogical, if I had means to temporarily stop the email crazy spammer, then it would be more easier to study the problem....
If this is my case, what can I do?
repair table config;
I've tried to do some pull/push with a clone of the repo created with "fork" (an android app), but nothing happened
These things (git operations and crashed config tables) have nothing to do with each other.
Blablanet, I think Mike wanted to comment in another place, in another post...No one has posted those things that are there in the comment.
Allow me to let you in on a dirty little secret. SQL server implementations have bugs. Now you're probably cursing me for telling you that and "next you'll tell me there's no Santa Claus". Well I hate to be the one to break the news to you, but there's no Santa Claus either.
In particular when using one of the MySQL server implementations, we chose to use the MyISAM table type (which has known crash problems), as opposed to the INNODB type, which is (ahem) "crash proof". Why did we make this decision, and why didn't we use INNODB?
Go back to the first statement. SQL server implementations have bugs. I've seen crashed MyISAM tables. I've also seen crashed INNODB tables. None of these were running hubzilla incidentally, which has nothing to do with crashed tables. It is strictly an SQL *server* problem. The difference is that if a MyISAM table crashes, YOU CAN USUALLY FIX IT. If an INNDODB table crashes, YOU CAN'T FIX IT. YOU'RE TOTALLY STUFFED. If you don't have a backup, ALL YOUR DATA IS COMPLETELY IRRECOVERABLE.
Anyway that is why we don't use "crash proof" tables. You are welcome to use them if you want, but if one crashes (and this happens), you're out of luck. I can't help you. Nobody can help you. You're stuck pretty much going into the binary files and trying to figure out which bits are wrong and manually editing them. I know because I've had to do this. I wouldn't wish it on anybody. But hey, if you trust that it will never crash, go for it. We had a conversion script in Friendica. It will probably work here with very little change.
Since we have a lot of novice administrators using this software that don't know the difference between a web app and an SQL server, I thought it was prudent to provide them with the most reliable system possible. That doesn't mean an SQL server that can't crash tables, since this is a myth. That means one that you can usually get your data back when it eventually stuffs up.
In particular when using one of the MySQL server implementations, we chose to use the MyISAM table type (which has known crash problems), as opposed to the INNODB type, which is (ahem) "crash proof". Why did we make this decision, and why didn't we use INNODB?
Go back to the first statement. SQL server implementations have bugs. I've seen crashed MyISAM tables. I've also seen crashed INNODB tables. None of these were running hubzilla incidentally, which has nothing to do with crashed tables. It is strictly an SQL *server* problem. The difference is that if a MyISAM table crashes, YOU CAN USUALLY FIX IT. If an INNDODB table crashes, YOU CAN'T FIX IT. YOU'RE TOTALLY STUFFED. If you don't have a backup, ALL YOUR DATA IS COMPLETELY IRRECOVERABLE.
Anyway that is why we don't use "crash proof" tables. You are welcome to use them if you want, but if one crashes (and this happens), you're out of luck. I can't help you. Nobody can help you. You're stuck pretty much going into the binary files and trying to figure out which bits are wrong and manually editing them. I know because I've had to do this. I wouldn't wish it on anybody. But hey, if you trust that it will never crash, go for it. We had a conversion script in Friendica. It will probably work here with very little change.
Since we have a lot of novice administrators using this software that don't know the difference between a web app and an SQL server, I thought it was prudent to provide them with the most reliable system possible. That doesn't mean an SQL server that can't crash tables, since this is a myth. That means one that you can usually get your data back when it eventually stuffs up.
the good thing about hubzilla is that if if you every x days or months make a major export of channels (including the content), then indeed you prevent for those days that problems can arise.
My advice is always to have the exported data ready to be imported.
Prevention is better than cure.
My advice is always to have the exported data ready to be imported.
Prevention is better than cure.
repair table config;too simple;
I've done this sql query on the database, but the obsessive cron message won't stop!
considered the comments of Mike and also Blablanet, although useful, we have moved away from the post issue. We are talking about an issue in OpenShift. There is no way to stop this system of sending millions of emails from openshift?!. it seems absurd that a person does not have "the power" to stop this process in an easy way .
