I don know what is happening or where is the root of this problem. I just installed the Zabbix Web Service and I created a new scheduled report. When I click the Test button when editing/creating a report I will obtain a report to my email account.
But when I save a scheduled report a will obtain an error in the Info column:
Cannot calculate report start time: [75] Value too large for defined data type
I tried also the 12h time format instead of the 24h time format (just to be sure) but not helped.
Here I am sending a scheduled report which I created:
I didn't found any information about this error so I assume there is a problem somewhere in my configuration.
My setup:
Azure VM - Ubuntu server version 20.04.2 LTS
Zabbix Composed installation (Docker) version 5.4.0
I think I solve it when I activate and set the property:
PHP_TZ=Europe\xxxxxx
inside the .env_web file and also set the same time zone into the zabbix UI and also to the host system.
After these changes I have never received this error again.
Related
I am using couchbase server 6.0.2 image from RedHat
https://access.redhat.com/containers/?tab=overview&get-method=registry-tokens#/registry.connect.redhat.com/couchbase/server
in openshift.
The Pod is running but does not react to http://localhost:8091. The Logs show the error shown below.
I have 3 questions:
Why is whoami failing in the entrypoint?
Why isn't the server responding on port 8091?
Does the couchbase server image require root permissions?
It seems the couchbase/server image is expecting to be run as root, then creates its own user couchbase and group couchbase.
At the end it's running an entrypoint script and in there checking if the user running the whole thing, is actually the user couchbase by executing the whois command.
This is not the case if you just run it in openshift, as the container will be run as some "random" unprivileged user.
This leads to a set of consecutive failures:
Here You will find the evaluation that is done in the entrypoint.sh.
Now the whois command is failing since there is not actual user just said random UID. that failing, leaves the first part of the evaluation blank, which will result in a failure.
This is a bug in the couchbase/server image and as such you should, if time allows contribute to fixing by opening an issue against that repo.
I get this error when deploying a package to SQL 2012 SSISDB catalog:
A .NET Framework error occurred during execution user-defined routine or aggregate "deploy-project-internal":
System.Data.SqlClient.SqlException: The locale identifier (LCID) 9242 is not supported by SQL Server
......
I had a very similar issue (different LCID) and took me weeks to resolve it but I hope is the same issue you where having and it helps for any other users.
So somehow something got bad installed on the SQL Server, the service account that is setup to run the SQL Server Service doesn't have all the necessary permissions.
I tracked this issue down to a very specific procedure, try to execute on the SSISDB the procedure [catalog].[check_schema_version] and you should be getting the same error message you are getting.
If executing the procedure gives you the same error, then the soultion is going to be the same. You basically need to change the account that is running SQL Server Service (not Integration Services) to be a local admin, and change the Locale on the RegEdit for that Local Admin acccount to be the one you want.
TO do so, do the following:
Execute on Command Prompt the following to get the SID:
wmic useraccount where name='Administrator' get sid (Replace
Administrator by your Local Admin Account)
Go to RegEdit -> HKEY_USERS -> [SID Local Admin] -> Control Panel ->
International and change keys "Locale" and "LocaleName" for the
desired region,(in my case it was Locale 00000409, LocaleName en-US)
Open Windows Services, look for the SQL SERVER (MSSQLSERVER) and
change the running account to be your local admin
Restart the Service
That should be it. I figured all that out thanks to the combination of these 2 pages:
https://www.facebook.com/allaboutssis/posts/329497130467714
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/9f409937-772a-41bd-8270-7804fdd5b94e/failure-in-deploying-ssis-project-from-ssdt-to-sqlserver-2014?forum=sqlintegrationservices&prof=required
Also I had a similar issue with the LCID for the Palestinian State which was added recently to windows and it seems that the SSIS doesn't recognize this LCID. So changing the windows LCID to another one solved the problem (from contorl panel then regions)
I solved it in the following way.
First, check in Services which user SQL Server (MSSQLSERVER) runs as:
Next, open the Registry Editor and navigate to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\. Find which ID the user has. In my case, the user MSSQLSERVER has the ID S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003:
When you have the user's ID, in the Registry Editor, go to the path Computer\HKEY_USERS\[USER ID]\Control Panel\International. In my case, the path is Computer\HKEY_USERS\S-1-5-80-3880718306-3832830129-1677859214-2598158968-1052248003\Control Panel\International. There you will find two keys named Locale and LocaleName:
In my case, they had the following values:
Locale = 00000c00
LocaleName = en-SE
Change them to:
Locale = 00000409
LocaleName = en-US
Next, restart the service SQL Server (MSSQLSERVER).
After that, I was able to deploy the project:
I run a series of DTS packages via SQL Server (2000) Agent every night. They have been running ok for years until I added a couple of transform data tasks that pick up info from another local SQL Server (2008).
The odd thing is that the tasks run ok for about a week and then fail with the error 'Login failed for user domain\$duplicate-1889'. I don't run these packages using this user account, in fact I don't think it's a real account. I have a Windows account called dbadmin which has been set up on both servers to have access. This dbadmin account is used to start up the SQL Server Agent service and run the scheduled jobs.
When the jobs fail, all have to do to get them to run again is to stop and restart SQL Server Agent. But after a week they fail again with the same issue. Also, it's not the same day of the week each time.
I checked the Windows event log and although I can see the error, I can't figure out its cause. Any help or pointers would be appreciated.
The domain\$duplicate-1889 name looks like machine account. Every machine joined to a domain has such an account in the domain that the machine uses to authenticate to the domain.
The passwords for those accounts are automatically handled and the password is periodically changed automatically. By default that interval is 30 days but if is changed to once a week in your environment maybe there's a problem when the computer's password has been updated?
It is possible to disable the automatic changing maybe that's worth trying to see if the problem dissapears.
I'm trying to execute the command in the Windows console:
C:\SphinxSearch\bin\indexer --all --config C:\SphinxSearch\sphinx.conf
But I get an error:
ERROR: index 'indexname': sql_connect: Can't create TCP/IP socket
(10093) (DSN=mysql://root:*#localhost:3306/test).
A data source is mysql. Before the server restart everyone works fine.
How can I fix it?
I'm having the same error 10093. It's a windows error code by the way. In my case it occurs when trying to run the indexer through the system account via a scheduled task. If I'm running it directly as administrator, there's not a problem.
According to the site above:
Either your application hasn't called WSAStartup(), or WSAStartup() failed, or--possibly--you are accessing a socket which the current active task does not own (i.e. you're trying to share a socket between tasks).
In my case I'm thinking it might be the last one, some security problem due to user SYSTEM being used in my scheduled task. I was able to solve it by using my admin user instead: in the scheduled task, I set to use my local admin account with the option to "Run when user is logged on or not" and "Do not store password". I've also checked "Run with highest privileges". This seems to have done the trick as now my indexes are rotating on schedule.
I have a SSIS 2005 package that is up and running in our production environment. The package uses an SMTP Connection Manager to send an e-mail message out to a designated user. We have a scheduled job that executes this package, and also overrides the SMTP connection string so that the package can target the test or production mail server, which makes it possible to keep a single service on both our test and production servers, just configured differently.
We recently changed the server name of our production mail server and went into the scheduled job and changed the command prompt values that run to point to the new server. However, the next morning the job failed and the error log indicated that the job tried to connect to the old mail server.
Is there something I'm missing to updating the SSIS package parameters? Do I have to delete the existing package, and then reimport and reschedule the job again in order for the new server change to hold?
The dba's from where I work had a similar issue. They had to change a job's running parameters, but it seems like running the job with modified parameters only worked the first time they ran it. After that run, it kept using the old values in subsequent runs. They had to repackage the damned thing.
If you are using the package configuration feature? It can be picky on the order of execution. There's some more info here: http://msdn.microsoft.com/en-us/library/ms141132.aspx